创建型设计模式（一）

1、简单工厂模式

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

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

开放―封闭原则。

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

       效果：

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

       适用的范围：

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

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

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

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

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

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

       适用的范围：    

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

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

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

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

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

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

       适用范围：

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

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

4、总结

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