Aha！设计模式(42)-创建型模式的讨论(1)

Aha！设计模式(42)-创建型模式的讨论(1)

《设计模式》观点

用一个系统创建的那些对象的类对系统进行参数化有两种常用方法。一种是生成创建对象的类的子类；这对应于使用Factory Method模式。这种方法的主要缺点是，仅为了改变产品类，就可能需要创建一个新的子类。这样的改变可能是级联的（cascade）。例如，如果产品的创建者本身是由一个工厂方法创建的，那么你也必须重定义它的创建者。

另一种对系统进行参数化的方法更多的依赖于对象复合：定义一个对象负责明确产品对象的类，并将它作为该系统的参数。这是Abstract Factory、Builder和Prototype模式的关键特征。所有这三个模式都涉及到创建一个新的负责创建产品对象的“工厂对象”。Abstract Factory由这个工厂对象产生多个类的对象。 Builder由这个工厂对象使用一个相对复杂的协议，逐步创建一个复杂产品。 Prototype由该工厂对象通过拷贝原型对象来创建产品对象。在这种情况下，因为原型负责返回产品对象，所以工厂对象和原型是同一个对象。

作者观点

以下为作者的理解，和《设计模式》中的观点略有不同。请各位自己判断采纳。

替换系统（或者是）使用的对象的具体类型有以下种常用的方式。

一种方式是准备某些类的子类，这些子类可以创建需要替换的对象。工厂方法模式就属于这种方式。这种方法的主要缺点是，为了改变产品类，一般需要创建新的子类。另外这种方式在需要构建多种产品的时候，会让构建对象的类的职责显得比较模糊。

另一种方式是定义一个专门负责生成产品的类，将它作为系统的参数。这种情况包括抽象工厂模式和建造者（Builder）模式。这两种方式需要专门用于生成对象的类。

最后一种方式是，通过复制已有对象的到新对象。对应的是原型模式。如果仅从功能是否单一的角度来说，将原型模式分到第一种方式更加合理。

上述内容也可以参照下图理解：

无论哪种方式，都坚持一个原则，就是不让使用者接触实际的产品类。看不见，摸不着，自然就没有了耦合性。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。