工厂模式

一、简单工厂

    对象的创建方式有很多，常用new来创建。但是这种做法在一些情况下，有很多不好的地方。比如创建操作散落在代码的多处、对象的创建职责和使用职责混合到一起等等。简单工厂可以一定程度上解决该问题。通常的做法是对被创建的多个类进行抽象，将公共成员和方法放到抽象类中。不同的类继承抽象类，对细节进行不同的实现。然后创建一个工厂类，将类实例化的操作封装到工厂类的静态工厂方法中，通过不同的参数来创建不同类的对象。

    还有一种简化的做法是，将静态工厂方法放到实体类的公共抽象父类中。

    优点：

• 对象的创建和使用分离
• 客户端无需关心创建细节
• 通过引入配置文件，可以不修改代码的情况下修改创建类型

    缺点：

• 工厂类包含了所有类的创建逻辑，职责过重。
• 扩展性不好，增加新类型就需要修改工厂类。

    适用场景：

• 被创建类型少，且不易变

二、工厂方法模式

    简单工厂在一定程度上解决了创建和使用的分离问题，但也有一定弊端。扩展类时，需要修改工厂方法，违反开闭原则。此时引入工厂方法模式。

    工厂方法模式不再将所有类的实例化都放到一个工厂方法内，而是将工厂类也按照被创建类一样分级，有一个抽象工厂和多个实力工厂。每个工厂负责创建一种实体类型。这样就将具体的创建逻辑分化出来，当有扩展时，只需新加一种实体类和对应的实体工厂类，解决了简单工厂违反开闭原则的问题。这种模式是使用频率最高的设计模式之一，被广泛运用于各种API库和框架。

    优点：

• 对象的创建和使用分离
• 通过工厂的抽象和扩展实现，分离了各种类的实例化细节，扩展性更好，更符合开闭原则。

    缺点：

• 每增加新产品时，需要编写产品类，还需要编写对应的工厂类，增加了复杂度，也增加了类的数量和执行负担。

三、抽象工厂模式

    工厂方法随着产品类型的增加，类的数量成对数的增加。在一些情况下，抽象工厂模式可以缓解这个问题。

    在这里引入了产品簇的概念。何为产品簇？产品簇是具有某些相同特征或联系的不同产品等级的产品的合集。比如一个系统内，有黑按钮、白按钮、黑输入框、白输入框。这里按钮和输入框为两个产品等级，不同等级中的产品又按黑和白产生了一些共同特征和联系，在这里黑按钮和黑输入框就是一个产品簇，同理，白按钮和白输入框也是一个产品簇。抽象工厂模式，为每一个产品簇创建一个工厂，这样工厂的数量从产品的数量减少到了产品簇的数量。

    优点：

• 减少了工厂数量，降低复杂性
• 同簇产品可以方便的产生关联或同时创建
• 增加产品簇时，不用修改原有代码，只需扩展新的工厂，符合开闭原则

    缺点：

• 增加产品等级时，需要对所有工厂进行修改，违反开闭原则。