设计模式总结之创建型模式

来源:互联网 发布:mac 安装websphere 编辑:程序博客网 时间:2024/05/02 00:05

    经过一个月的时间,终于把设计模式23种统统的敲了一遍,但是总结工作最为重要,下面我来总结一下吧!

    比较几种创建型模式的优缺点,仔细考察这几种模式的区别和相关性。

    第一类是工厂模式,工厂模式专门负责将大量有共同接口的类实例化。工厂模式可以动态决定将哪一个类实例化,不必事先知道每次要实例化哪一个类。

工厂模式有三种形态:简单工厂模式;工厂方法模式;抽象工厂模式。前两者是类的创建模式,后者是对象的创建模式。

简单工厂:

简单工厂模式是由一个工厂类根据传入的参量决定创建出哪一种产品类的实例,涉及工厂角色(Creator)、抽象产品(Product)角色及具体产品(Concrete Product)角色等三个角色。

优点:

模式的核心是工厂类,该类中含有必要的判断逻辑,可以决定在什么时候创建哪一个产品类的实例,客户端可以免除直接创建产品对象的责任,而仅仅负责“消费”产品。

简单工厂模式实现了对责任的分割。

缺点:

当产品类有复杂的多层次等级结构时,工厂类只有它自己。

模式中工厂类集中了所有的产品创建逻辑,形成一个无所不知的全能类。

将多个创建逻辑放在一个类中,当产品类有不同接口种类时,工厂类需要判断在什么时候创建某种产品,使得系统在将来进行功能扩展时较为困难。

该模式采用静态方法作为工厂方法,而静态方法无法由子类继承,因此工厂角色无法形成基于继承的等级结构。

简单工厂模式只在有限的程度上符合“开-闭”原则。

结构图如下:


工厂方法:

定义一个用于创建对象的接口,让子类决定实例化哪一个类。Factory Method使一个类的实例化延迟到其子类。工厂方法模式是简单工厂模式的进一步抽象和推广,其基本思想是定义一个创建产品对象的工厂接口,将实际创建工作推迟到子类中。

优点:

多态性:客户代码可以做到与特定应用无关,适用于任何实体类

子类可以重写新的实现,也可以继承父类的实现。加一层间接性,增加了灵活性。

良好的封装性,代码结构清晰。扩展性好,在增加产品类的情况下,只需要适当修改具体的工厂类或扩展一个工厂类,就可“拥抱变化”屏蔽产品类。产品类的实现如何变化,调用者都不需要关心,只需关心产品的接口,只要接口保持不变,系统中的上层模块就不会发生变化。

典型的解耦框架。高层模块只需要知道产品的抽象类,其他的实现类都不需要关心,符合迪米特法则,符合依赖倒置原则,符合里氏替换原则。

缺点:

需要Creator和相应的子类作为工厂方法的载体,如果应用模型确实需要creator和子类存在,则很好;否则的话,需要增加一个类层次。

结构图如下:


抽象工厂:

提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类,客户端不必指定产品的具体类型,创建多个产品族中的产品对象。

优点:

分离了具体的类,一个工厂封装创建产品对象的责任和过程,它将客户与类的实现分离易于交换产品系列,只需改变具体的工厂就可以使用不同的产品配置。

有利于产品的一致性,当一个系列中的产品对象被设计成一起工作时,一个应用一次只能使用同一个系列中的对象。

缺点:

难以支持新的产品等级结构,支持新的产品等级结构就要扩展抽象工厂接口。

结构图如下:


单例模式: 

一个类仅有一个实例,自行实例化并向整个系统提供一个访问它的全局访问点。确保一个类只能被实例化一次。

优点:

跨平台:使用合适的中间件,可以把singleton模式扩展为跨多个JVM和多个计算机工作。

适用于任何类:只需把一个类的构造函数变成私有的,并且在其中增加相应的静态函数和变量,就可以把这个类变为singleton。

可以通过派生创建:给定一个类,可以创建它的一个singleton子类。

延迟求值:如果singleton从未使用过,那么就绝不会创建它。

缺点:

摧毁方法未定义: 没有好的方法去摧毁一个singleton,或者解除其责任。

不能继承:从singleton派生的类并不是singleton。如果要使其成为singleton,必须要增加所需的静态函数和变量。

效率问题:每次调用instance方法都会执行if语句,多余。

不透明性: singleton的使用者知道它们正在使用一个singleton ,因为它们必须要调用instance方法。 

结构图如下:


建造者模式:

将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。建造模式利用一个导演者对象和具体建造者对象一个一个地建造出所有的零件,从而建造出完整的对象。

优点:

建造模式的使用使得产品的内部表象可以独立地变化。使用建造模式可以使客户端不必知道产品内部组成的细节。

每一个Builder都相对独立,而与其他的Builder无关。

模式所建造的最终产品更易于控制。

缺点:

建造者模式的“加工工艺”是暴露的,这样使得建造者模式更加灵活,也使得工艺变得对客户不透明。

结构图如下:


原型模式

用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象。以一个已有的对象作为原型,通过它来创建新的对象。在增加新的对象的时候,新对象的细节创建工作由自己来负责,从而使新对象的创建过程与框架隔离开来。

优点:

原型模式允许动态地增加或减少产品类。由于创建产品类实例的方法是产品类内部具有的,因此增加新产品对整个结构没有影响。

原型模式提供简化的创建结构。工厂方法常需要有一个与产品类相同的等级结构,而原型模式不需要。

具有给一个应用软件加载新功能的能力。

产品类不需要非得有任何事先确定的等级结构,因为原型模式适用于任何的等级结构。

缺点:

每一个类必须配备一个克隆方法。

配备克隆方法需要对类的功能进行通盘考虑,这对于全新的类不是很难,但对于已有的类不一定很容易,特别当一个类引用不支持串行化的间接对象,或者引用含有循环结构的时候。

结构图如下:


关系总结:

1  工厂方法模式是简单工厂模式的扩展,由于使用了多态性,工厂方法模式保持了简单工厂模式的优点,而且克服了它的缺点。如果只有一个具体工厂类,工厂方法模式可以改造为简单工厂模式。

2  抽象工厂经常用工厂方法来实现。

3. 抽象工厂模式是对象的创建模式,是工厂方法模式的进一步推广。抽象工厂模式是所有形态的工厂模式中最为抽象和最具一般性的一种形态。

4  工厂方法模式针对的是一个产品等级结构;抽象工厂模式需要面对多个产品等级结构。


0 0