创建型设计模式（一）

一、简单工厂模式

       定义：定义一个工厂类，它可以根据参数的不同返回不同类的实例，被创建的实例通常都具有共同的父类。

       问题：产品类的职责过重，违反了单一职责原则；如果增加新的职责，就要修改产品类的源代码，违反了

开放—封闭原则。

       解决方案：提供专门的工厂建立对象，将对象的使用和创建分开。

                                             

       效果：

       (1) 工厂类包含必要的判断逻辑，可以决定在什么时候创建哪一个产品类的实例，客户端可以免除直接创建产品对象的职责，而仅仅“消费”产品。但是当工厂类负责创建的对象多的时候，逻辑判断也特别复杂，不利于系统的扩展和维护。
       (2) 客户端无须知道所创建的具体产品类的类名，只需要知道具体产品类所对应的参数即可。

       适用的范围：

       (1) 工厂类负责创建的对象比较少，由于创建的对象较少，不会造成工厂方法中的业务逻辑太过复杂。
       (2) 客户端只知道传入工厂类的参数，对于如何创建对象并不关心。

二、工厂方法模式（Factory Method)

     定义：一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。

       问题：在简单工厂中工厂类的职责有时太大，如果需求增加，那么我们就要对工厂类中的逻辑判断就要进行修改，这样就违背了开放——封闭原则。

       解决方案：根据依赖倒转原则，降低工厂类与分支的耦合度，将工厂类抽象出一个接口，这个接口有一个创建抽象产品的工厂方法，要生产具体产品类的工厂去实现这个接口。

       效果：工厂方法模式继承了简单工厂模式的优点，同时也弥补了简单工厂模式的不足。但是工厂方法简单工厂的内部逻辑判断移到了客户端代码中，如果增加想要的功能，本来是改工厂类的，但现在是修改客户端。 

       适用的范围：    

       （1）、客户端不需要知道具体产品类的类名，只需要知道所对应的工厂 。

       （2）、抽象工厂类通过其子类来指定创建哪个对象。                                      

三、抽象工厂模式（Abstract Factory)

     定义：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

       问题：在工厂方法模式的基础上，如果再添加一个类型的产品，则还需要添加一个工厂类 ，这样产生的类就会特别的多。                                                                                                                                                                                  解决方案：建立一个抽象工厂的接口，里面包括所有的产品创建的抽象方法。

       效果：提供了强大的工厂类，功能全面，但是等级结构复杂。

       适用范围：

       （1）、系统中有多个产品族，且每个产品族中的产品同时使用

       （2）、产品等级结构稳定和设计完成后，不会向系统中增加新的产品等级结构或者删除已有的产品等级结构。

四、总结

     工厂三兄弟中，他们是从低等级的不断优化完善延伸出来的。他们都有自己的优缺点，合适的场合使用！