今天是设计模式的第二讲，抽象工厂的设计模式，我们还是延续老办法，一步一步的、演变的来讲，先来看看一个对象创建的问题。
1、如何创建一个对象
常规的对象创建方法：
这样的创建对象没有任何问题，也可以很好的使用。但是如果有需求的变化，比如，如果我们换了一种道路呢，这时候就出现了问题。
new的问题：
-实现依赖，不能应对“具体实例化类型”的变化，Road是具体类型，所有使用到Road的地方都需要变化。如果经常变化，怎么解决具体类型的变化呢？
解决思路：
-封装变化点——哪里变化，封装哪里
-潜台词：如果没有变化，当然不需要额外的封装！
2、简单工厂模式的由来
先说明一点，“简单工厂模式”没有写在Gof的23种设计模式里面，它是“工厂模式”的引子。
变化点在“对象创建”，因此就封装“对象创建”
面向接口编程——依赖接口（此接口不是语言层面的Interface，此接口可以是：Interface&抽象类），而非依赖实现
最简单的解决方法：
这样做，可以隔离客户程序和具体Road类型的变化，客户程序依赖比较稳定的RoadFactory类型，这样一来，客户端的使用的接口就比较稳定了。
3、创建一系列相互依赖的对象
一个对象的问题解决了，那多个对象的创建问题怎么解决呢？
假设一个游戏开发场景：
我们需要构造“道路”、“房屋”、“地道”、“丛林”……等等对象
很不错，解决了一批对象的创建问题，这样可以保持客户程序使用接口的稳定性。
4、多批对象的创建
简单工厂的问题：
-不能应对“不同系列对象”的变化。比如有不同风格的游戏场景——对应不同风格的道路、房屋、地道……客户程序相对稳定，但是静态的简单工厂却可能成为变化点。
如何解决：
-使用面向对象的技术来“封装”变化点，我们就可以使用“抽象工厂”设计模式
动机（Motivation）
在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作；同时，由于需求的变化，往往存在更多系列对象的创建工作。
如何应对这种变化？如何绕过常规的对象创建方法(new)，提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合？
意图（Intent）
提供一个接口，让该接口负责创建一系列“相关或者相互依赖的对象”，无需指定它们具体的类。
结构（Structure）
ProductA1和ProductB1是一个系列，ProductA2和ProductB2是另一个系列。ConcreteFactory1是创建系列1的工厂方法，ConcreteFactory2是创建系列2的工厂方法。客户程序Client只依赖了AbstractFactory和AbstractProductA、AbstractProductB，也就是客户程序不依赖于具体实现，而是只依赖与抽象类。
如果现在需要创建一个系列3运用到客户程序，我们只需要再写一个系列3的工厂，继承自AbstractFactory，这个工厂提供了2个实现：
CreateProductA();
CreateProductB();
它们分别返回ProductA3（继承自AbstractProductA）、ProductB3（继承自AbstractProductB）。
也就是说，如果新增了系列3，Client程序可以完全不用改动，可能只需要该一些配置文件，增加一些新dll就可以应对变化。
游戏框架中的AbstractFactory应用
这个例子里，Road就是AbstractProductA1，Building就是AbstractProductB1，FacilitiesFactory就是AbstractFactory。
客户程序
可以看出，客户程序依赖的全部是抽象类，在客户程序代码中没有出现过任何具体的实现类。因为在系列需要变化的时候，是不需要改变抽象类的，只是增加一个抽象类的实现而已，又由于客户程序只依赖于抽象，所以系列变化的时候客户程序完全无需变化。
一个现代风格系列的实现
具体现代风格系列工厂实现
应用到具体程序（现代风格）
应用到具体程序（经典风格）
可以看出，风格由Modern改变为Classic的时候，我们封装好的GameManager客户程序没有改变，这就是我们想要的结果。GameManager的逻辑非常复杂，现在它的稳定，能够大大方便我们的工作。
AbstractFactory模式的几个要点
1.如果没有应对“多系列对象创建”的需求变化，则没有必要使用AbstractFactory模式，这时候使用简单的静态工厂完全可以。
2."系列对象"指的是这些对象之间有相互依赖、或作用的关系，例如游戏开发场景中“道路”与“房屋”的依赖，“道路”与“地道”的依赖。
3.AbstractFactory模式主要在于应对“新系列”的需求变动。其缺点在于难以应对“新对象”的需求变动。
4.AbstractFactory模式经常喝FactoryMethod模式共同组合来应对“对象创建”的需求变化。
例如，如果是风格不经常变化，而是其他内容变化（例如今天要添加道路的类、明天要添加沙漠的类），这样用这种抽象工厂模式反而会把系统搞的很糟糕，因为抽象工厂类中的子类变化了，所有实现抽象工厂的类都需要去变化，重新实现，重新编译和部署。
也就是说关键要看变化的方向和轴线在哪里。如果变化的轴线在多风格，那抽象工厂模式就很适用；如果变化的轴线在抽象工厂里面的对象，就最好不要使用这种模式。
.NET框架中的AbstractFactory应用
在ASP.Net编译的时候，首先把aspx页面文件先编译成一个类，然后再把CodeBehind又编译成一个类，CodeBehind的类继承自Page类，而aspx页面的类又继承自CodeBehind类。在aspx页面中处理的WebControl和HtmlControl实际上用到了AbstractFactory的运用，但是这个运用更多是体现在业务层次。
Builder模式和AbstractFactory模式的区别
Builder模式更强调的是对象组成部分的构建的过程，而且这个构建的过程很稳定，但是各个组成部分在变化，最后组合成一个整体的对象。
AbstractFactory模式构建的是一系列相互依赖、相互关联的对象集合。