意图：
提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
抽象工厂模式在生活中的实例
咱们继续拿怎么穿衣服来说明这个抽象工厂模式。
就拿你来说吧。工作了，为了参加一些聚会，肯定有两套或多套衣服吧，比如说有商务装（成套，一系列具体产品）、时尚装（成套，一系列具体产品），甚至对于一个家庭来说，可能有商务女装、商务男装、时尚女装、时尚男装，这些也都是成套的，即一系列具体产品。咱们假设一种情况(现实中是不存在的,要不然,没法进入共产主义了,但有利于说明抽象工厂模式)，在你的家中，某一个衣柜（具体工厂）只能存放某一种这样的衣服（成套，一系列具体产品），每次拿这种成套的衣服时也自然要从这个衣柜中取出了。用OO的思想去理解，所有的衣柜（具体工厂）都是衣柜类的（抽象工厂）某一个，而每一件成套的衣服又包括具体的上衣（某一具体产品），裤子（某一具体产品），这些具体的上衣其实也都是上衣（抽象产品），具体的裤子也都是裤子（另一个抽象产品）。
分析：
要好好去读上面那个实例，虽然有点绕嘴，其实只要用心去读，分清了抽象工厂模式的各个角色，对理解设计模式是非常重要的。理解头绪，然后接合简单工厂模式、工厂方法模式对工厂家族的了解，再加上抽象工厂模式的意图，头脑中差不多有一个雏型了吧。好了，咱们一起来分析一下。。
先把各个角色揪出来。
抽象工厂：虚拟的衣柜，它只是个概念而已。在项目中可能是一个接口或抽象类，定义规则，取出上衣，裤子。
具体工厂：具体的存在的衣柜，它用于存放某一种成套的衣服，换句话说，这种成套的衣服都是从这个衣柜中取出的。在项
目中继承于抽象工厂，实现抽象工厂中的方法，取出具体产品，某一件上衣，某一条裤子。
抽象产品：虚拟的衣服，也只是个概念。在项目中可能是多个接口或抽象类，定义规则，有什么特性，起什么作用。
具体产品：具体的实际存在的产品，它指的就是用于组装成某一套衣服的某一件上衣或裤子。它继承自某一个抽象产品。实
现抽象产品中制定的规则，特性。
它们之间怎么联系呢？客户在用的时候，依赖的又是什么呢？
客户在要的时候，首先要说出你要的什么系列的衣服，然后根据它的要求生成一个具体工厂的实例，剩下的工作就都是这个倒霉的具体工厂了，它会根据自己的实现生成一个上衣，生成一个裤子，然后把它交给客户。客户在这一过程中并不知道具体工厂都做了什么。也就是说，客户只依赖于抽象工厂和抽象产品了。在初始化的时候会用到一次具体工厂类名，我们根据.NET特有的反射机制又可以把这个在客户端唯一的具体的非抽象类放到一个应用程序配置文件中，防止它变化。
这就符合了设计模式中的“开放--封闭”原则，依赖倒转原则，里氏代换原则等等。
优点：
- 隔离了具体类的生成，客户不需要知道怎样生成了每一个具体产品，什么时间生成的。它将客户与具体的类分离，依赖于抽象类，耦合性低。
- 一个产品族中的多个对象被设计成一起工作，它能够保证客户端始终只使用一个产品族中的对象。这对一些需要根据当前环境来决定其行为的软件系统来说，是非常实用的一种设计模式。
- 它有利于更换产品系列，由于客户端只依赖于抽象类，具体类也被写到应用程序配置文件中，更换产品系列时，只须更改一下具体工厂名就行了。
缺点：
- 难以支持新种类的产品。难以扩展抽象工厂以生产新种类的产品。这是因为抽象工厂几口确定了可以被创建的产品集合，支持新种类的产品就需要扩展该工厂接口，这将涉及抽象工厂类及其所有子类的改变。
应用情景：
- 同一个产品族的产品在一起使用时，而且它们之间是相互依赖的，不可分离
- 系统需要由相互关联的多个对象来构成
- 你想提供一组对象而不显示它们的实现过程，只显示它们的接口
- 系统不应当依赖某一些具体产品类。
应用场景举例：
- 游戏开发中的多风格系列场景
- 系统更改皮肤
- 支持多种观感标准的用户界面工具箱（Kit）。
http://www.cnblogs.com/anlyren/archive/2008/01/31/abstract_factory.html
http://www.cnblogs.com/Terrylee/archive/2005/12/13/295965.html