宜昌网站seo收费/html友情链接代码

《设计模式》观点

 

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

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

 

作者观点

 

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

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

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

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

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

 

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

 

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

 

注：

 

本文中蓝色粗体文字都引自《设计模式》一书。

 

觉得本文有帮助？请分享给更多人。

更新文章，请扫描下面二维码，关注微信公众号【面向对象思考】