一、简单工厂模式

简单工厂模式Simple Factory，又称静态工厂方法模式。它是类的创建模式。是由一个工厂对象决定创建出哪一种产品类的实例，是不同的工厂方法模式的一个特殊实现。

优点：

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

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

缺点：

u 当产品类有复杂的多层次等级结构时，工厂类只有它自己。以不变应万变。

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

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

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

二、工厂方法模式

工厂方法模式Factory Method，又称多态性工厂模式。在工厂方法模式中，核心的工厂类不再负责所有的产品的创建，而是将具体创建的工作交给子类去做。该核心类成为一个抽象工厂角色，仅负责给出具体工厂子类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。

优点：

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

u 子类提供挂钩。基类为工厂方法提供缺省实现，子类可以重写新的实现，也可以继承父类的实现。-- 加一层间接性，增加了灵活性

u 连接并行的类层次结构。

u 良好的封装性，代码结构清晰。

u 扩展性好，在增加产品类的情况下，只需要适当修改具体的工厂类或扩展一个工厂类，就可“拥抱变化”。

u 屏蔽产品类。产品类的实现如何变化，调用者都不需要关心，只需关心产品的接口，只要接口保持不变，系统中的上层模块就不会发生变化。

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

缺点：

u 需要Creator和相应的子类作为factory method的载体，如果应用模型确实需要creator和子类存在，则很好；否则的话，需要增加一个类层次。

三、抽象工厂模式

抽象工厂模式Abstract Factory，又称工具箱模式。它提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类 – 客户端不必指定产品的具体类型，创建多个产品族中的产品对象。

优点：

u 分离了具体的类，一个工厂封装创建产品对象的责任和过程，它将客户与类的实现分离

易于交换产品系列，只需改变具体的工厂就可以使用不同的产品配置。

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

缺点：

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

四、单例模式

单例模式Singleton：一个类仅有一个实例，自行实例化并向整个系统提供一个访问它的全局访问点。

优点：

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

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

u 可以通过派生创建：给定一个类，可以创建它的一个singleton子类。

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

缺点：

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

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

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

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

五、多例模式

多例模式Multiton：多例模式为对象的创建模式。多例模式中的多例类可以有多个实例，而且多例类必须自己创建、管理自己的实例，并向外界提供自己的实例。

特点：

u 多例类可有多个实例。

u 多例类必须自己创建、管理自己的实例，并向外界提供自己的实例。

六、建造模式

建造模式Builder：建造模式是对象的创建模式。建造模式可以将一个产品的内部表象与产品的生成过程分割开来，从而可以使一个建造过程生成具有不同的内部表象的产品对象。将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

优点：

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

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

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

缺点：

u 创建者模式比较符合产品差别不大的对象的创建，如果差别很大，就会导致非常多的具体的创建者，这时候最好结合工厂方法模式。

七、原型模式

原型模式 Prototype ：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。

优点：

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

u 原型模式提供简化的创建结构。工厂方法常需要有一个与产品类相同的等级结构，而原型模式不需要。对Java设计者，原型模式有其特有方便之处，Java语言已将原型模式设计到语言模型里。如果善于利用原型模式和Java语言特点，可事半功倍。

u 具有给一个应用软件加载新功能的能力。如：一个分析web服务器的记录文件的应用软件，针对每一种记录文件格式，都可以由一个相应的“格式类”负责。如果出现了应用软件所不支持的新的web服务器，只需提供一个格式类的克隆，并在客户端登记即可，不必给每个软件的用户提供一个全新的软件包。

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

缺点：

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

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

八、相关性

几种模式的相关性：

u 简单工厂是基础。

u 工厂方法模式是简单工厂模式的进一步抽象和推广，定义了工厂接口，将实际的创建工作推迟到子类中，如果只有一个具体工厂类，可以改造为简单工厂模式。

u 抽象工厂模式是对象的创建模式，是工厂方法模式的进一步推广，抽象工厂模式经常用工厂方法来实现。抽象工厂模式是所有形态的工厂模式中最为抽象和最具一般性的一种形态。

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

u 单例模式有比较强烈的物理意义，可以用在许多细微的地方，不一定与类层次关联，与其他创建型模式并不矛盾，可以用单例模式来实现其他模式中的对象，如抽象工厂模式、建造模式和原型模式等。

u 多例模式是单例模式的自然推广。

u 建造模式与抽象工厂模式相比，都可以创建复杂对象，但建造模式着重于一步步构造一个复杂对象，抽象工厂模式着重于一系列的产品对象，相应地，建造模式是在最后的一步返回产品，抽象工厂模式的产品是立即返回的。可以搭配使用抽象工厂模式和建造模式，客户端通过调用建造模式，间接地调用抽象工厂模式的工厂角色，工厂模式返还不同产品族的零件，建造模式把它们组装起来。

u 原型模式与抽象工厂模式竞争，根据应用需求进行取舍。

巴特西

C#设计模式-创建型模式（转）

一、简单工厂模式

二、工厂方法模式

三、抽象工厂模式

四、单例模式

五、多例模式

六、建造模式

七、原型模式

八、相关性

最新文章

热门文章