简单工厂、工厂方法、抽象工厂、Builder 模式 笔记整理

1、简单工厂模式

首先，需要表明的是，简单工厂模式并不是 23 种设计模式之一。它是工厂方法模式的一个弱化版本。

且简单工厂模式又称为静态工厂模式。

在该模式中，一般不定义工厂抽象类，而是直接将工厂类的工厂方法改为静态方法（因此才有静态工厂模式的说法）。

静态的工厂方法可以根据参数的不同返回不同类的实例。

简单工厂模式专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。

适用场景

工厂类负责创建的对象比较少：由于创建的对象较少，不会造成工厂方法中的业务逻辑太过复杂。

客户端只知道传入工厂类的参数，对于如何创建对象不关心：客户端既不需要关心创建细节，甚至连类名都不需要记住，只需要知道类型所对应的参数。

优点

通过使用工厂类，外界不再需要关心如何创造各种具体的产品，只要提供一个产品的名称作为参数传给工厂，就可以直接得到一个想要的产品对象，并且可以按照接口规范来调用产品对象的所有功能（方法）。
构造容易，逻辑简单。

缺点

1. 简单工厂模式中的 if else 判断非常多，完全是 Hard Code，如果有一个新产品要加进来，就要同时添加一个新产品类，并且必须修改工厂类，再加入一个 else if 分支才可以， 这样就违背了 “开放-关闭原则”中的对修改关闭的准则了。当系统中的具体产品类不断增多时候，就要不断的修改工厂类，对系统的维护和扩展不利。
2. 一个工厂类中集合了所有的类的实例创建逻辑，违反了高内聚的责任分配原则，将全部的创建逻辑都集中到了一个工厂类当中，所有的业务逻辑都在这个工厂类中实现。什么时候它不能工作了，整个系统都会受到影响。因此一般只在很简单的情况下应用，比如当工厂类负责创建的对象比较少时。
3. 简单工厂模式由于使用了静态工厂方法，造成工厂角色无法形成基于继承的等级结构。

2、工厂方法模式

工厂父类负责定义创建产品对象的公共接口，而工厂子类则负责生成具体的产品对象，这样做的目的是将产品类的实例化操作延迟到工厂子类中完成，即通过工厂子类来确定究竟应该实例化哪一个具体产品类。

即某个具体的产品类由对应的工厂子类生产。

适用场景

1. 一个类不知道它所需要的对象的类：在工厂方法模式中，客户端不需要知道具体产品类的类名，只需要知道所对应的工厂即可，具体的产品对象由具体工厂类创建；客户端需要知道创建具体产品的工厂类。
2. 一个类通过其子类来指定创建哪个对象：在工厂方法模式中，对于抽象工厂类只需要提供一个创建产品的接口，而由其子类来确定具体要创建的对象，利用面向对象的多态性和里氏代换原则，在程序运行时，子类对象将覆盖父类对象，从而使得系统更容易扩展。
3. 将创建对象的任务委托给多个工厂子类中的某一个，客户端在使用时可以无须关心是哪一个工厂子类创建产品子类，需要时再动态指定，可将具体工厂类的类名存储在配置文件或数据库中。

优点

1. 在工厂方法模式中，工厂方法用来创建客户所需要的产品，同时还向客户隐藏了哪种具体产品类将被实例化这一细节，用户只需要关心所需产品对应的工厂，无须关心创建细节，甚至无须知道具体产品类的类名。

2. 基于工厂角色和产品角色的多态性设计是工厂方法模式的关键。它能够使工厂可以自主确定创建何种产品对象，而如何创建这个对象的细节则完全封装在具体工厂内部。工厂方法模式之所以又被称为多态工厂模式，是因为所有的具体工厂类都具有同一抽象父类。

3. 使用工厂方法模式的另一个优点是在系统中加入新产品时，无须修改抽象工厂和抽象产品提供的接口，无须修改客户端，也无须修改其他的具体工厂和具体产品，而只要添加一个具体工厂和具体产品就可以了。这样，系统的可扩展性也就变得非常好，完全符合“开闭原则”，这点比简单工厂模式更优秀。

缺点

1. 在添加新产品时，需要编写新的具体产品类，而且还要提供与之对应的具体工厂类，系统中类的个数将成对增加，在一定程度上增加了系统的复杂度，有更多的类需要编译和运行，会给系统带来一些额外的开销。

2. 由于考虑到系统的可扩展性，需要引入抽象层，在客户端代码中均使用抽象层进行定义，增加了系统的抽象性和理解难度，且在实现时可能需要用到 DOM、反射等技术，增加了系统的实现难度。

3、抽象工厂模式

提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。抽象工厂模式又称为 Kit 模式（Kit: 套件）。

适用场景

1. 一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节，这对于所有类型的工厂模式都是重要的。

2. 系统中有多于一个的产品族，而每次只使用其中某一产品族。与工厂方法模式的区别

3. 属于同一个产品族的产品将在一起使用，这一约束必须在系统的设计中体现出来。

4. 系统提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于具体实现。

如创建主题框架，定义工厂接口，亮色主题工厂生产对应的亮色的 Button、TextView，暗色主题也生产对应的控件。

优点

1. 分离了接口与实现，客户端不用关心实现，只是面向产品的接口编程，实现了高内聚低耦合的设计目的。

2. 增加新的具体工厂和产品族很方便，因为一个具体的工厂实现代表的是一个产品族，无须修改已有系统，符合 “开闭原则”。（注意，这里是说产品族，而不是产品类，比如上面的主题框架，要增加一个粉色主题的，则增加对应的工厂，实现产品族的生产方法即可）

缺点

1. 类文件的爆炸性增加

2. 不太容易扩展新的产品类，增加新的产品类就要修改抽象工厂（即工厂接口，定义新的产品类的创建方法），那么所有的具体的工厂类均会被修改。（还是上面的主题框架，假设要新增一个产品类，即新增一个控件类，则需要先修改工厂接口，定义新的控件生产方法，然后修改其子类，实现定义的方法）

4、Builder 模式

将一个复杂对象的构建与它的表示分离，是同样的构建过程可以创建不同的表示。

说的通俗一点，就是构建的时候，使用同样的参数构建方法，但是传入的内容不同，就会得到不同的配置的表现。比如 AlterDialog，可能根据不同的需求会有不同 title、content 等，因此在构建的时候设置不同的参数，在表示的时候就会又对应的不同的内容。

适用场景

初始化一个对象特别复杂，如参数多，且很多参数都具有默认值的情况。

优点

1. 良好的封装性， 使用建造者模式可以使客户端不必知道产品内部组成的细节；
2. 建造者独立，容易扩展；
3. 在对象创建过程中会使用到系统中的一些其它对象，这些对象在产品对象的创建过程中不易得到；
4. 能够屏蔽对象参数设置的细节，使用者只需要按照对外提供的方法来传入参数即可，也能提高参数的设置的灵活度（如不必要按照顺序往构造方法传入参数等）。还可以达到限制使用者行为的作用，因为限定了参数设置的方法。

缺点

1. 会产生多余的 Builder 对象以及 Director 对象（用于封装构建过程，并不是必须的），消耗内存；
2. 对象的构建过程暴露。

5. 四者的不同

简单工厂模式：一个工厂方法创建不同类型的对象。

工厂方法模式：一个具体的工厂类负责创建一个具体的对象类型。

抽象工厂模式：一个具体的工厂类负责创建一系列相关的对象。

Builder 模式：对象的构建与表示分离，更注重对象的创建过程。

构建者模式是将构建与表示分离，而工厂模式是隐藏对象的实例过程，统一对外提供创建的实例。

参考文章

1、https://lrh1993.gitbooks.io/android_interview_guide/content/design-mode/Builder-Pattern.html
2、《Android 源码设计模式解析与实战》（第 2 版）