《设计模式》观点   用一个系统创建的那些对象的类对系统进行参数化有两种常用方法。一种是生成创建对象的类的子类；这对应于使用Factory Method模式。这种方法的主要缺点是，仅为了改变产品类，就可能需要创建一个新的子类。这样的改变可能是级联的（cascade）。例如，如果产品的创建者本身是由一个工厂方法创建的，那么你也必须重定义它的创建者。 另一种对系统进行参数化的方法更多的依赖于对象复合：定义一个对象负责明确产品对象的类，并将它作为该系统的参数。这是Abstract Factory、Builder和Prototype模式的关键特征。所有这三个模式都涉及到创建一个新的负责创建产品对象的“工厂对象”。Abstract Factory由这个工厂对象产生多个类的对象。 Builder由这个工厂对象使用一个相对复杂的协议，逐步创建一个复杂产品。 Prototype由该工厂对象通过拷贝原型对象来创建产品对象。在这种情况下，因为原型负责返回产品对象，所以工厂对象和原型是同一个对象。   作者观点   以下为作者的理解，和《设计模式》中的观点略有不同。请各位自己判断采纳。 替换系统（或者是）使用的对象的具体类型有以下种常用的方式。 一种方式是准备某些类的子类，这些子类可以创建需要替换的对象。工厂方法模式就属于这种方式。这种方法的主要缺点是，为了改变产品类，一般需要创建新的子类。另外这种方式在需要构建多种产品的时候，会让构建对象的类的职责显得比较模糊。 另一种方式是定义一个专门负责生成产品的类，将它作为系统的参数。这种情况包括抽象工厂模式和建造者（Builder）模式。这两种方式需要专门用于生成对象的类。 最后一种方式是，通过复制已有对象的到新对象。对应的是原型模式。如果仅从功能是否单一的角度来说，将原型模式分到第一种方式更加合理。   上述内容也可以参照下图理解：   无论哪种方式，都坚持一个原则，就是不让使用者接触实际的产品类。看不见，摸不着，自然就没有了耦合性。   注：   本文中蓝 {MOD}粗体文字都引自《设计模式》一书。   觉得本文有帮助？请分享给更多人。 阅读更多更新文章，请扫描下面二维码，关注微信公众号【面向对象思考】