首页 > 代码库 > 创建型设计模式(一)
创建型设计模式(一)
一、简单工厂模式
定义:定义一个工厂类,它可以根据参数的不同返回不同类的实例,被创建的实例通常都具有共同的父类。
问题:产品类的职责过重,违反了单一职责原则;如果增加新的职责,就要修改产品类的源代码,违反了
开放—封闭原则。
解决方案:提供专门的工厂建立对象,将对象的使用和创建分开。
效果:
(1) 工厂类包含必要的判断逻辑,可以决定在什么时候创建哪一个产品类的实例,客户端可以免除直接创建产品对象的职责,而仅仅“消费”产品。但是当工厂类负责创建的对象多的时候,逻辑判断也特别复杂,不利于系统的扩展和维护。
(2) 客户端无须知道所创建的具体产品类的类名,只需要知道具体产品类所对应的参数即可。
适用的范围:
(1) 工厂类负责创建的对象比较少,由于创建的对象较少,不会造成工厂方法中的业务逻辑太过复杂。
(2) 客户端只知道传入工厂类的参数,对于如何创建对象并不关心。
二、工厂方法模式(Factory Method)
定义:一个用于创建对象的接口,让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。
问题:在简单工厂中工厂类的职责有时太大,如果需求增加,那么我们就要对工厂类中的逻辑判断就要进行修改,这样就违背了开放——封闭原则。
解决方案:根据依赖倒转原则,降低工厂类与分支的耦合度,将工厂类抽象出一个接口,这个接口有一个创建抽象产品的工厂方法,要生产具体产品类的工厂去实现这个接口。
效果:工厂方法模式继承了简单工厂模式的优点,同时也弥补了简单工厂模式的不足。但是工厂方法简单工厂的内部逻辑判断移到了客户端代码中,如果增加想要的功能,本来是改工厂类的,但现在是修改客户端。
适用的范围:
(1)、客户端不需要知道具体产品类的类名,只需要知道所对应的工厂 。
(2)、抽象工厂类通过其子类来指定创建哪个对象。
三、抽象工厂模式(Abstract Factory)
定义:提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。
问题:在工厂方法模式的基础上,如果再添加一个类型的产品,则还需要添加一个工厂类 ,这样产生的类就会特别的多。 解决方案:建立一个抽象工厂的接口,里面包括所有的产品创建的抽象方法。
效果:提供了强大的工厂类,功能全面,但是等级结构复杂。
适用范围:
(1)、系统中有多个产品族,且每个产品族中的产品同时使用
(2)、产品等级结构稳定和设计完成后,不会向系统中增加新的产品等级结构或者删除已有的产品等级结构。
四、总结
工厂三兄弟中,他们是从低等级的不断优化完善延伸出来的。他们都有自己的优缺点,合适的场合使用!
创建型设计模式(一)