zwj9367的博客

单例模式同时解决了两个问题，所以违反了单一职责原则：保证一个类只有一个实例。为该实例提供一个全局访问节点。为什么会有人想要控制一个类所拥有的实例数量？最常见的原因是控制某些共享资源（例如数据库或文件）的访问权限。它的运作方式是这样的：如果你创建了一个对象，同时过一会儿后你决定再创建一个新对象，此时你会获得之前已创建的对象，而不是一个新对象。注意，普通构造函数无法实现上述行为，因为构造函数的设计决定了它必须总是返回一个新对象。还记得你用过的那些存储重要对象的全局变量吗？

如果你有一个对象，并希望生成与其完全相同的一个复制品，你该如何实现呢？首先，你必须新建一个属于相同类的对象。然后，你必须遍历原始对象的所有成员变量，并将成员变量值复制到新对象中。不错！但有个小问题。并非所有对象都能通过这种方式进行复制，因为有些对象可能拥有私有成员变量，它们在对象本身以外是不可见的。直接复制还有另外一个问题。因为你必须知道对象所属的类才能创建复制品，所以代码必须依赖该类。

假设有这样一个复杂对象，在对其进行构造时需要对诸多成员变量和嵌套对象进行繁复的初始化工作。这些初始化代码通常深藏于一个包含众多参数且让人基本看不懂的构造函数中；甚至还有更糟糕的情况，那就是这些代码散落在客户端代码的多个位置。如果为每种可能的对象都创建一个子类，这可能导致程序过于复杂：例如， 我们来思考如何创建一个房屋（House）对象。建造一栋简单的房屋，首先你需要建造四面墙和地板，安装房门和一套窗户，然后再建造一个屋顶。

假设你正在开发一款家具商店模拟器。你的代码中包括一些类，用于表示：●一系列相关产品，例如椅子（Chair）、沙发（Sofa）和咖啡桌（CoffeeTable）●系列产品的不同变体，例如你可以使用现代（Modern）、维多利亚（Victorian）和装饰风艺术（ArtDeco）等风格生成这些产品你需要设法单独生成每件家具对象，这样才能确保其风格一致。如果顾客收到的家具风格不一样，他们可不会开心。此外， 你也不希望在添加新产品或新风格时修改已有代码。

工厂方法是一种创建型设计模式，其在父类中提供一个创建对象的方法，允许子类决定实例化对象的类型。假设你正在开发一款物流管理应用。最初版本只能处理卡车运输，因此大部分代码都在位于名为“卡车”的类中。一段时间后，这款应用变得极受欢迎。你每天都能收到十几次来自海运公司的请求，希望应用能够支持海上物流功能。物流应用这可是个好消息。但是代码问题该如何处理呢？目前，大部分代码都与 卡车 类相关。在程序中添加 轮船 类需要修改全部代码。