抽象工厂模式abstractfactory
工厂模式的实现方式
工厂模式的实现方式
工厂模式有以下几种实现方式：
1. 简单工厂模式：由一个工厂类负责创建对象，根据传入的参数不同，工厂类可以创建不同的对象。
这种方式对于创建简单的对象较为适用，但是如果需要创建复杂的对象或者对象之间存在复杂的依赖关系，则不太适用。
2. 工厂方法模式：定义一个创建对象的工厂接口，由具体的工厂类来实现这个接口，每个具体工厂类负责创建一种具体的对象。
这种方式可以避免简单工厂模式中的一个类负责创建所有对象的问题，而且可以方便地扩展创建新的对象。
3. 抽象工厂模式：定义一个抽象工厂接口，具体的工厂类实现这个接口并负责创建一组相关的对象。
这种方式可以创建一组相关的对象，而不仅仅是单个对象。
这三种实现方式都可以用来创建对象，具体选择哪一种方式取决于具体的需求和设计。
23种设计模式记忆口诀
23种设计模式记忆口诀设计模式是软件开发中常见的解决方案模板，它们能够解决许多常见的设计问题。
为了帮助记忆23种设计模式，可以使用下面这个口诀来记忆：Creational Patterns（创建型模式）:1. Singleton（单例模式）：一个类能产生一个实例，全局访问。
2. Builder（建造者模式）：分步骤创建复杂对象，易拓展。
3. Factory Method（工厂方法模式）：子类决定实例化哪个对象。
4. Abstract Factory（抽象工厂模式）：创建一组相关对象，不依赖具体类。
5. Prototype（原型模式）：通过复制现有对象来创建新对象。
Structural Patterns（结构型模式）:6. Adapter（适配器模式）：将类的接口转换为客户端希望的接口。
7. Bridge（桥接模式）：将抽象部分与实际部分分离。
将对象组合成树形结构来表示部分整体的层次结构。
9. Decorator（装饰器模式）：动态地给对象添加功能。
10. Facade（外观模式）：提供一个统一的接口，简化客户端使用。
11. Flyweight（享元模式）：共享细粒度对象，减少内存使用。
12. Proxy（代理模式）：控制对其他对象的访问。
Behavioral Patterns（行为型模式）:13. Chain Of Responsibility（责任链模式）：将请求的发送者和接收者解耦，多个对象都可能处理请求。
将请求封装成对象，可以用参数化方式处理。
15. Iterator（迭代器模式）：提供一种遍历集合的统一接口。
16. Mediator（中介者模式）：将多个对象之间的复杂关系解耦。
17. Memento（备忘录模式）：将对象的状态保存起来，以后可以恢复。
18. Observer（观察者模式）：当一个对象改变状态时，依赖它的对象都会收到通知。
19. State（状态模式）：对象的行为随状态的改变而改变。
以下属于创建型设计模式的
以下属于创建型设计模式的1. 工厂模式（Factory Pattern）：工厂模式是一种创建型设计模式，它定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个。
工厂方法让类把实例化推迟到子类。
2. 抽象工厂模式（Abstract Factory Pattern）：抽象工厂模式提供了一种将一组相关或相互依赖的对象创建为一个家族的方式，而无需指定具体的类。
抽象工厂模式让客户端使用抽象的接口来创建一组相关的产品，而无需关心具体的实现。
3. 单例模式（Singleton Pattern）：单例模式是一种创建型设计模式，它保证一个类只有一个实例，并提供一个全局访问点来访问这个实例。
单例模式常用于控制资源的访问，例如数据库连接池、线程池等。
4. 建造者模式（Builder Pattern）：建造者模式是一种将一个复杂对象的构建与表示分离的创建型设计模式。
它允许同样的构建过程可以创建不同的表示。
5. 原型模式（Prototype Pattern）：原型模式是一种通过复制现有对象来创建新对象的创建型设计模式。
通过克隆一个已有的对象来生成新的对象，而无需再通过构造函数进行初始化。
6. 简单工厂模式（Simple Factory Pattern）：简单工厂模式实际上并不是一种设计模式，它更像是一种编程习惯。
简单工厂模式通过一个工厂类中的静态方法来创建对象，客户端只需要通过传入不同的参数即可获取不同的对象实例。
7. 对象池模式（Object Pool Pattern）：对象池模式是一种通过预先创建和维护一组可重复使用的对象来提高性能的设计模式。
通过将已创建的对象存放在一个对象池中，以后需要使用相同类型的对象时可以直接从对象池中获取，而不需要再次创建。
8. 多例模式（Multiton Pattern）：多例模式是一种创建型设计模式，它允许一个类有多个实例，并提供一个访问这些实例的全局访问点。
以上是一些常见的创建型设计模式，每种模式都有其适用的场景和优势。
简单工厂工厂方法抽象工厂策略模式策略与工厂的区别
简单工厂工厂方法抽象工厂策略模式策略与工厂的区别简单工厂、工厂方法、抽象工厂以及策略模式在软件开发中都是常用的设计模式，它们都是为了解决不同对象的创建和使用问题。
下面将对它们进行详细的介绍，并比较它们之间的区别。
1. 简单工厂模式（Simple Factory Pattern）：简单工厂模式是由一个工厂类根据传入的参数决定创建哪种产品的设计模式。
它包含三个角色：工厂类负责创建产品，产品类定义产品的具体实现，客户端通过工厂类获取产品对象。
简单工厂模式将对象的创建与使用进行了分离，增加了灵活性，但是违反了开闭原则，因为每次新增产品都需要修改工厂类。
2. 工厂方法模式（Factory Method Pattern）：工厂方法模式是指定义一个创建产品对象的接口，但是由子类决定实例化哪个类。
这样可以将产品的实例化延迟到子类中进行，满足了开闭原则。
工厂方法模式由抽象工厂类、具体工厂类和抽象产品类、具体产品类组成。
具体工厂类负责创建具体产品类的实例，抽象产品类定义了产品的接口。
客户端通过抽象工厂类获取产品对象。
工厂方法模式解决了简单工厂模式的缺点，但是增加了类的个数。
3. 抽象工厂模式（Abstract Factory Pattern）：抽象工厂模式是指提供一个创建一系列相关或互相依赖对象的接口，而无需指定具体的类。
抽象工厂模式由抽象工厂类、具体工厂类和抽象产品类、具体产品类组成。
抽象工厂类定义了创建产品的接口，具体工厂类负责创建具体产品。
抽象产品类定义了产品的接口，具体产品类实现了产品的具体实现。
客户端通过抽象工厂类获取产品对象。
抽象工厂模式提供了一种创建一系列产品对象的方法，但是增加新产品时需要修改所有的工厂类。
4. 策略模式（Strategy Pattern）：策略模式是指定义了一系列的算法，并将每个算法封装起来，使得它们可以互相替换，使得算法的选择和使用可以独立于客户端。
策略模式由抽象策略类、具体策略类和环境类组成。
常见23种模式概述
常见23种模式概述：1）抽象工厂模式（Abstract Factory）：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
2）适配器模式（Adapter）：将一个类的接口转换成客户希望的另外一个接口。
适配器模式使得原本由于接口不兼容而不能一起工作的类可以一起工作。
3）桥梁模式（Bridge）：将抽象部分与它的实现部分分离，使它们都可以独立地变化。
4）建造模式（Builder）：将一个复杂对象的构建与它的表示分离，使同样的构建过程可以创建不同的表示。
5）责任链模式（Chain of Responsibility）：为解除请求的发送者和接收者之间耦合，而使多个对象都有机会处理这个请求。
将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它。
6）命令模式（Command）：将一个请求封装为一个对象，从而可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可取消的操作。
7）合成模式（Composite）：将对象组合成树形结构以表示“部分－整体”的层次结构。
它使得客户对单个对象和复合对象的使用具有一致性。
8）装饰模式（Decorator）：动态地给一个对象添加一些额外的职责。
就扩展功能而言，它能生成子类的方式更为灵活。
9）门面模式（Facade）：为子系统中的一组接口提供一个一致的界面，门面模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
10）工厂方法（Factory Method）：定义一个用于创建对象的接口，让子类决定将哪一个类实例化。
Factory Method 使一个类的实例化延迟到其子类。
11）享元模式（Flyweight）：运用共享技术以有效地支持大量细粒度的对象。
12）解释器模式（Interpreter）：给定一个语言，定义它的语法的一种表示，并定义一个解释器，该解释器使用该表示解释语言中的句子。
13）迭代子模式（Iterator）：提供一种方法顺序访问一个聚合对象中的各个元素，而又不需暴露该对象的内部表示。
23种设计模式 详解
23种设计模式详解设计模式是指面向对象编程中，经过多次验证、被广泛接受的代码实现方法。
这些设计模式可以帮助开发者更快地解决问题，提高代码的可读性、可维护性、可扩展性。
目前，常用的设计模式有23种。
下面，我们来详细介绍一下这23种设计模式。
1. 单例模式(Singleton)单例模式是一种只允许生成一个实例的模式。
在实例化对象时，单例模式的生成过程比较特殊，需要先判断该类是否已经实例化过，如果已经实例化，则直接返回已有的实例对象，否则再进行实例化。
2. 工厂模式(Factory)工厂模式是一种生产对象实例的设计模式。
它将对象实例的生成过程封装在一个工厂类中，客户端需要对象时，只需要调用工厂类中对应的方法即可。
3. 抽象工厂模式(Abstract Factory)抽象工厂模式是一种扩展了工厂模式的模式。
它可以生成一系列相关或相互依赖的对象实例。
具体实现时，通常需要定义一个抽象工厂类和一些具体工厂类，来生产各种相关的对象实例。
4. 建造者模式(Builder)建造者模式是一种用于构建复杂对象的模式。
它将一个复杂对象的构建过程分解成多个简单的步骤，然后通过一个指挥者来管理这些步骤的执行，最终构建出一个复杂的对象。
5. 原型模式(Prototype)原型模式是一种通过复制已有对象来创建新对象的模式。
一般来说，系统中的对象包含大量相同或相似的部分，通过复制对象可以帮助我们节省生成对象的时间和资源。
6. 适配器模式(Adapter)适配器模式是一种将不兼容接口转换为兼容接口的模式。
具体实现时，需要定义一个适配器类，该类实现了客户端所期望的接口，而且还包装了原有不兼容的接口，使其能够兼容客户端期望的接口。
7. 桥接模式(Bridge)桥接模式是一种将抽象部分与其实现部分分离开来的模式。
具体实现时，需要定义抽象部分和实现部分的接口，然后定义一个桥接类，将抽象部分和实现部分联系起来。
8. 组合模式(Composite)组合模式是一种将具有相同属性和方法的对象组合成树形结构的模式。
23种设计模式记忆口诀
23种设计模式记忆口诀根据内容要求，对23种设计模式进行简要说明，并整理成口诀。
设计模式是软件开发中常用的一种解决方案，它提供了面向对象设计和编程中常见问题的解决思路和方法。
根据GoF（Gang of Four）的分类，设计模式可以分为创建型、结构型和行为型三种类型，共23种设计模式。
1. 创建型模式（Creational Patterns）：- 工厂方法模式（Factory Method Pattern）：定义一个用于创建对象的接口，但由子类决定实例化的类。
- 抽象工厂模式（Abstract Factory Pattern）：提供一个创建一系列相关对象或依赖对象的接口，而无须指定它们的具体类。
- 单例模式（Singleton Pattern）：确保一个类只有一个实例，并提供一个全局访问点。
- 原型模式（Prototype Pattern）：用于创建重复性对象的一个原型。
- 建造者模式（Builder Pattern）：将一个复杂对象的构建和表示分离，使得同样的构建过程可以创建不同的表示。
2. 结构型模式（Structural Patterns）：- 适配器模式（Adapter Pattern）：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的类可以一起工作。
- 桥接模式（Bridge Pattern）：将抽象部分和它真正的实现分离，使它们独立的变化。
- 装饰器模式（Decorator Pattern）：动态地将责任附加到对象上，扩展功能。
- 外观模式（Facade Pattern）：为子系统中的一组接口提供一个统一的接口，以简化系统的使用。
3. 行为型模式（Behavioral Patterns）：- 策略模式（Strategy Pattern）：定义一系列算法，将每个算法封装起来，并使它们可以相互替换。
- 模板方法模式（Template Method Pattern）：定义一个算法的骨架，由子类实现具体步骤。
工厂模式简介和应用场景
⼯⼚模式简介和应⽤场景⼀、简介⼯⼚模式主要是为创建对象提供了接⼝。
⼯⼚模式按照《Java与模式》中的提法分为三类：1. 简单⼯⼚模式(Simple Factory)2. ⼯⼚⽅法模式(Factory Method)3. 抽象⼯⼚模式(Abstract Factory)⼆、简单⼯⼚模式我喜欢吃⾯条，抽象⼀个⾯条基类，(接⼝也可以)，这是产品的抽象类。
public abstract class INoodles {/*** 描述每种⾯条啥样的*/public abstract void desc();}先来⼀份兰州拉⾯（具体的产品类）：public class LzNoodles extends INoodles {@Overridepublic void desc() {System.out.println("兰州拉⾯上海的好贵家⾥才5 6块钱⼀碗");}}程序员加班必备也要吃泡⾯（具体的产品类）：public class PaoNoodles extends INoodles {@Overridepublic void desc() {System.out.println("泡⾯好吃可不要贪杯");}}还有我最爱吃的家乡的⼲扣⾯（具体的产品类）：public class GankouNoodles extends INoodles {@Overridepublic void desc() {System.out.println("还是家⾥的⼲扣⾯好吃 6块⼀碗");}}准备⼯作做完了，我们来到⼀家“简单⾯馆”（简单⼯⼚类），菜单如下：public class SimpleNoodlesFactory {public static final int TYPE_LZ = 1;//兰州拉⾯public static final int TYPE_PM = 2;//泡⾯public static final int TYPE_GK = 3;//⼲扣⾯public static INoodles createNoodles(int type) {switch (type) {case TYPE_LZ:return new LzNoodles();case TYPE_PM:return new PaoNoodles();case TYPE_GK:default:return new GankouNoodles();}}}简单⾯馆就提供三种⾯条（产品），你说你要啥，他就给你啥。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
抽象工厂模式概述在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作；同时由于需求的变化，往往存在着更多系列对象的创建工作。
如何应对这种变化？如何绕过常规的对象的创建方法（new），提供一种“封装机制”来避免客户程序和这种“多系列具·体对象创建工作”的紧耦合？这就是我们要说的抽象工厂模式。
意图提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类模型图逻辑模型：物理模型：生活中的例子抽象工厂的目的是要提供一个创建一系列相关或相互依赖对象的接口，而不需要指定它们具体的类。
这种模式可以汽车制造厂所使用的金属冲压设备中找到。
这种冲压设备可以制造汽车车身部件。
同样的机械用于冲压不同的车型的右边车门、左边车门、右前挡泥板、左前挡泥板和引擎罩等等。
通过使用转轮来改变冲压盘，这个机械产生的具体类可以在三分钟内改变。
抽象工厂之新解虚拟案例中国企业需要一项简单的财务计算：每月月底，财务人员要计算员工的工资。
员工的工资 = (基本工资 + 奖金 - 个人所得税)。
这是一个放之四海皆准的运算法则。
为了简化系统，我们假设员工基本工资总是4000美金。
中国企业奖金和个人所得税的计算规则是:奖金 = 基本工资(4000) * 10%个人所得税 = (基本工资 + 奖金) * 40%我们现在要为此构建一个软件系统（代号叫Softo），满足中国企业的需求。
案例分析奖金(Bonus)、个人所得税(Tax)的计算是Softo系统的业务规则(Service)。
工资的计算(Calculator)则调用业务规则(Service)来计算员工的实际工资。
工资的计算作为业务规则的前端(或者客户端Client)将提供给最终使用该系统的用户(财务人员)使用。
针对中国企业为系统建模根据上面的分析，为Softo系统建模如下：代码：针对美国企业为系统建模为了拓展国际市场，我们要把该系统移植给美国公司使用。
美国企业的工资计算同样是: 员工的工资 = 基本工资 + 奖金 - 个人所得税。
但是他们的奖金和个人所得税的计算规则不同于中国企业:美国企业奖金和个人所得税的计算规则是:奖金 = 基本工资 * 15 %个人所得税 = (基本工资 * 5% + 奖金 * 25%)根据前面为中国企业建模经验，我们仅仅将ChineseTax、ChineseBonus修改为AmericanTax、AmericanBonus。
修改后的模型如下：代码:整合成通用系统让我们回顾一下该系统的发展历程：最初，我们只考虑将Softo系统运行于中国企业。
但随着MaxDO公司业务向海外拓展， MaxDO 需要将该系统移植给美国使用。
移植时，MaxDO不得不抛弃中国企业的业务规则类ChineseTax和ChineseBonus，然后为美国企业新建两个业务规则类: AmericanTax,AmericanBonus。
最后修改了业务规则调用Calculator 类。
结果我们发现：每当Softo系统移植的时候，就抛弃原来的类。
现在，如果中国联想集团要购买该系统，我们不得不再次抛弃AmericanTax,AmericanBonus，修改回原来的业务规则。
一个可以立即想到的做法就是在系统中保留所有业务规则模型，即保留中国和美国企业工资运算规则。
通过保留中国企业和美国企业的业务规则模型，如果该系统在美国企业和中国企业之间切换时，我们仅仅需要修改Caculator类即可。
让移植工作更简单前面系统的整合问题在于：当系统在客户在美国和中国企业间切换时仍然需要修改Caculator代码。
一个维护性良好的系统应该遵循“开闭原则”。
即：封闭对原来代码的修改，开放对原来代码的扩展（如类的继承，接口的实现）我们发现不论是中国企业还是美国企业，他们的业务运规则都采用同样的计算接口。
于是很自然地想到建立两个业务接口类Tax，Bonus，然后让AmericanTax、AmericanBonus和ChineseTax、ChineseBonus分别实现这两个接口，据此修正后的模型如下：代码:为业务规则增加工厂方法然而，上面增加的接口几乎没有解决任何问题，因为当系统的客户在美国和中国企业间切换时Caculator代码仍然需要修改。
只不过修改少了两处，但是仍然需要修改ChineseBonus,ChineseTax部分。
致命的问题是：我们需要将这个移植工作转包给一个叫Hippo的软件公司。
由于版权问题，我们并未提供Softo系统的源码给Hippo公司，因此Hippo公司根本无法修改Calculator，导致实际上移植工作无法进行。
为此，我们考虑增加一个工具类(命名为Factory)，代码如下：不错，我们解决了一个大问题，设想一下：当该系统从中国企业移植到美国企业时，我们现在需要做什么？答案是: 对于Caculator类我们什么也不用做。
我们需要做的是修改Factory类，修改结果如下：为系统增加抽象工厂方法很显然，前面的解决方案带来了一个副作用：就是系统不但增加了新的类Factory，而且当系统移植时，移植工作仅仅是转移到Factory类上，工作量并没有任何缩减，而且还是要修改系统的源码。
从Factory类在系统移植时修改的内容我们可以看出: 实际上它是专属于美国企业或者中国企业的。
名称上应该叫AmericanFactory,ChineseFactory更合适.解决方案是增加一个抽象工厂类AbstractFactory，增加一个静态方法，该方法根据一个配置文件(App.config或者Web.config) 一个项(比如factoryName)动态地判断应该实例化哪个工厂类，这样，我们就把移植工作转移到了对配置文件的修改。
修改后的模型和代码：代码:采用上面的解决方案，当系统在美国企业和中国企业之间切换时，我们需要做什么移植工作？答案是: 我们仅仅需要修改配置文件，将factoryName的值改为American。
修改配置文件的工作很简单，只要写一篇幅配置文档说明书提供给移植该系统的团队(比如Hippo公司) 就可以方便地切换使该系统运行在美国或中国企业。
最后的修正（不是最终方案）前面的解决方案几乎很完美，但是还有一点瑕疵，瑕疵虽小，但可能是致命的。
考虑一下，现在日本NEC公司决定购买该系统，NEC公司的工资的运算规则遵守的是日本的法律。
如果采用上面的系统构架，这个移植我们要做哪些工作呢?1. 增加新的业务规则类JapaneseTax,JapaneseBonus分别实现Tax和Bonus接口。
2. 修改AbstractFactory的getInstance方法，增加elseif(factoryName.equals("Japanese")){....注意: 系统中增加业务规则类不是模式所能解决的，无论采用什么设计模式，JapaneseTax,JapaneseBonus总是少不了的。
（即增加了新系列产品）我们真正不能接受的是：我们仍然修要修改系统中原来的类(AbstractFactory)。
前面提到过该系统的移植工作，我们可能转包给一个叫Hippo的软件公司。
为了维护版权，未将该系统的源码提供给Hippo公司，那么Hippo公司根本无法修改AbstractFactory，所以系统移植其实无从谈起，或者说系统移植总要开发人员亲自参与。
代码:这样，在我们编写的代码中就不会出现Chinese，American，Japanese等这样的字眼了。
小结最后那幅图是最终版的系统模型图。
我们发现作为客户端角色的Calculator仅仅依赖抽象类，它不必去理解中国和美国企业具体的业务规则如何实现，Calculator面对的仅仅是业务规则接口Tax和Bonus。
Softo系统的实际开发的分工可能是一个团队专门做业务规则，另一个团队专门做前端的业务规则组装。
抽象工厂模式有助于这样的团队的分工: 两个团队通讯的约定是业务接口，由抽象工厂作为纽带粘合业务规则和前段调用，大大降低了模块间的耦合性，提高了团队开发效率。
完完全全地理解抽象工厂模式的意义非常重大，完完全全地理解抽象工厂模式的意义非常重大，可以说对它的理解是你对OOP理解上升到一个新的里程碑的重要标志。
学会了用抽象工厂模式编写框架类，你将理解OOP的精华:面向接口编程。
应对“新对象”抽象工厂模式主要在于应对“新系列”的需求变化。
其缺点在于难于应付“新对象”的需求变动。
如果在开发中出现了新对象，该如何去解决呢？这个问题并没有一个好的答案，下面我们看一下李建忠老师的回答：“GOF《设计模式》中提出过一种解决方法，即给创建对象的操作增加参数，但这种做法并不能令人满意。
事实上，对于新系列加新对象，就我所知，目前还没有完美的做法，只有一些演化的思路，这种变化实在是太剧烈了，因为系统对于新的对象是完全陌生的。
”实现要点●抽象工厂将产品对象的创建延迟到它的具体工厂的子类。
●如果没有应对“多系列对象创建”的需求变化，则没有必要使用抽象工厂模式，这时候使用简单的静态工厂完全可以。
●系列对象指的是这些对象之间有相互依赖、或作用的关系，例如游戏开发场景中的“道路”与“房屋”的依赖，“道路”与“地道”的依赖。
●抽象工厂模式经常和工厂方法模式共同组合来应对“对象创建”的需求变化。
●通常在运行时刻创建一个具体工厂类的实例，这一具体工厂的创建具有特定实现的产品对象，为创建不同的产品对象，客户应使用不同的具体工厂。
●把工厂作为单件，一个应用中一般每个产品系列只需一个具体工厂的实例，因此，工厂通常最好实现为一个单件模式。
●创建产品，抽象工厂仅声明一个创建产品的接口，真正创建产品是由具体产品类创建的，最通常的一个办法是为每一个产品定义一个工厂方法，一个具体的工厂将为每个产品重定义该工厂方法以指定产品，虽然这样的实现很简单，但它确要求每个产品系列都要有一个新的具体工厂子类，即使这些产品系列的差别很小。
优点●分离了具体的类。
抽象工厂模式帮助你控制一个应用创建的对象的类，因为一个工厂封装创建产品对象的责任和过程。
它将客户和类的实现分离，客户通过他们的抽象接口操纵实例，产品的类名也在具体工厂的实现中被分离，它们不出现在客户代码中。
●它使得易于交换产品系列。
一个具体工厂类在一个应用中仅出现一次——即在它初始化的时候。
这使得改变一个应用的具体工厂变得很容易。
它只需改变具体的工厂即可使用不同的产品配置，这是因为一个抽象工厂创建了一个完整的产品系列，所以整个产品系列会立刻改变。
●它有利于产品的一致性。
当一个系列的产品对象被设计成一起工作时，一个应用一次只能使用同一个系列中的对象，这一点很重要，而抽象工厂很容易实现这一点。
缺点●难以支持新种类的产品。
难以扩展抽象工厂以生产新种类的产品。