首页 > 代码库 > 创建型设计模式(一)

创建型设计模式(一)

一、简单工厂模式

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

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

开放—封闭原则。

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

                                             技术分享

       效果:

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

       适用的范围:

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

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

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

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

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

技术分享

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

       适用的范围:    

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

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

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

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

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

技术分享

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

       适用范围:

       (1)、系统中有多个产品族,且每个产品族中的产品同时使用

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

四、总结

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


创建型设计模式(一)