您当前的位置: 1 背景
以前粗枝大叶的看过设计模式，没有十分的努力的记忆，这次重新研究设计模式，想基本完全搞定这个具有提纲挈领的一个基础知识，设计模式，这里知识点比较分散，其实主要是个笔记性质，如果你真的感兴趣，可以结合全书来阅读，这里给大家提醒着本书很奇怪，大家慎重。
这篇博客主要针对的是创建型设计模式来展开的，也就是该书的第三章，讲述的
2 主要五种模型
创建模型这里仅仅有5种，我感觉其中
2.1 ABSTRACT FACTORY（ 抽象工厂） —对象创建型模式
2.1.1 意 图
提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
2.1.2 结构图
2.1.3 使用场景
- 一个系统要独立于它的产品的创建、组合和表示时。
- 一个系统要由多个产品系列中的一个来配置时。
- 当你要强调一系列相关的产品对象的设计以便进行联合使用时。
2.1.4 效果
- 它分离了具体的类， Abstract Factory模式帮助你控制一个应用创建的对象的类。因为一个工厂封装创建产品对象的责任和过程，它将客户与类的实现分离。客户通过它们的抽象接口操纵实例。产品的类名也在具体工厂的实现中被分离；它们不出现在客户代码中。
- 它使得易于交换产品系列， 一个具体工厂类在一个应用中仅出现一次—即在它初始化的时候。这使得改变一个应用的具体工厂变得很容易。它只需改变具体的工厂即可使用不同的产品配置，这是因为一个抽象工厂创建了一个完整的产品系列，所以整个产品系列会立刻改变。
- 它有利于产品的一致性 当一个系列中的产品对象被设计成一起工作时，一个应用一次只能使用同一个系列中的对象，这一点很重要。而Abstract Factory很容易实现这一点。
- 难以支持新种类的产品 ，难以扩展抽象工厂以生产新种类的产品。这是因为，Abstract Factory接口确定了可以被创建的产品集合。 支持新种类的产品就需要扩展该工厂接口，这将涉及Abstract Factory类及其所有子类的改变。我们会在实现一节讨论这个问题的一个解决办法
2.1.5 注意
文章貌似说可以在接口声明中添加一个方法。
2.2 BUILDER（ 生成器） —对象创建型模式
2.2.1 意图
将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示
2.2.2 结构图
2.2.3 使用场景
在以下情况使用B u i l d e r模式
- 当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。
- 当构造过程必须允许被构造的对象有不同的表示时。
2.2.4 效果
该模式有以下效果
- 它使你可以改变一个产品的内部表示 builder对象提供给导向器一个构造产品的抽象接口。该接口使得生成器可以隐藏这个产品的表示和内部结构。它同时也隐藏了该产品是如何装配的。因为产品是通过抽象接口构造的，你在改变该产品的内部表示时所要做的只是定义一个新的生成器。
- 它将构造代码和表示代码分开 builder模式通过封装一个复杂对象的创建和表示方式提高了对象的模块性。客户不需要知道定义产品内部结构的类的所有信息；这些类是不出现在builder接口中的。
- 它使你可对构造过程进行更精细的控制 builder模式与一下子就生成产品的创建型模式不同，它是在导向者的控制下一步一步构造产品的。仅当该产品完成时导向者才从生成器中取回它。因此 B u i l d e r接口相比其他创建型模式能更好的反映产品的构造过程。这使你可以
更精细的控制构建过程，从而能更精细的控制所得产品的内部结构
2.2.5 注意
这里貌似仅仅是为了传递几个参数然后新建一个对象。在《effectiove java》中说明这样可以俭省了大量的多参构造函数，并且书写更加方便。当然要在builder的各个调用函数中返回自己
2.3 FACTORY METHOD（ 工厂方法） —对象创建型模式
2.3.1 意图
定义一个用于创建对象的接口，让子类决定实例化哪一个类。 Factory Method使一个类的实例化延迟到其子类
2.3.2 结构图
2.3.3 使用场景
在下列情况下可以使用 Factory Method模式：
- 当一个类不知道它所必须创建的对象的类的时候。
- 当一个类希望由它的子类来指定它所创建的对象的时候。
- 当类将创建对象的职责委托给多个帮助子类中的某一个，并且你希望将哪一个帮助子类是代理者这一信息局部化的时候。
2.3.4 效果
工厂方法不再将与特定应用有关的类绑定到你的代码中。代码仅处理product接口；因此它可以与用户定义的任何 concreteproduct类一起使用。工厂方法的一个潜在缺点在于客户可能仅仅为了创建一个特定的 concreteproduct对象，就不得不创建 creater的子类。当creater子类不必需时，客户现在必然要处理类演化的其他方面；但是当客户无论如何必须创建 creater的子类时，创建子类也是可行的。下面是Factory Method模式的另外两种效果：
- 为子类提供挂钩（hook） 用工厂方法在一个类的内部创建对象通常比直接创建对象更灵活。 Factory Method给子类一个挂钩以提供对象的扩展版本。
- 连接平行的类层次 迄今为止，在我们所考虑的例子中，工厂方法并不往往只是被creater调用，客户可以找到一些有用的工厂方法，尤其在平行类层次的情况下
2.2.5 注意
这里可以通过上溯造型来实现获取不同发的类。例如context类中的getsystemservice（）函数通过传递一个sting来获取一个系统服务，这里要注意为了效率考虑。他里面有个hashmap来保存已经实例化的类（忘记是不是静态类），避免多次实例化
2.3 PROTOTYPE（ 原型） —对象创建型模式
2.4.1 意图
用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
2.4.2 结构图
2.4.3 使用场景
- 当一个系统应该独立于它的产品创建、构成和表示时，要使用prototype模式
- 当要实例化的类是在运行时刻指定时，例如，通过动态装载
- 为了避免创建一个与产品类层次平行的工厂类层次时；
- 当一个类的实例只能有几个不同状态组合中的一种时。建立相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一些
2.4.4 效果
prototype有许多和Abstract Factory和builder一样的效果：它对客户隐藏了具体的产品类，因此减少了客户知道的名字的数目。此外，这些模式使客户无需改变即可使用与特定应用相关的类。下面列出prototype模式的另外一些优点。
- 运行时刻增加和删除产品prototype允许只通过客户注册原型实例就可以将一个新的具体产品类并入系统。它比其他创建型模式更为灵活，因为客户可以在运行时刻建立和删除原型。
- 改变值以指定新对象 高度动态的系统允许你通过对象复合定义新的行为—例如，通过为一个对象变量指定值—并且不定义新的类。你通过实例化已有类并且将这些实例注册为客户对象的原型，就可以有效定义新类别的对象。客户可以将职责代理给原型，从而表现出新的行为。这种设计使得用户无需编程即可定义新“类”。实际上，克隆一个原型类似于实例化一个类。prototype模式可以极大的减少系统所需要的类的数目。
- 改变结构以指定新对象 许多应用由部件和子部件来创建对象。例如电路设计编辑器就是由子电路来构造电路的 。为方便起见，这样的应用通常允许你实例化复杂的、用户定义的结构，比方说，一次又一次的重复使用一个特定的子电路。Prototype模式也支持这一点。我们仅需将这个子电路作为一个原型增加到可用的电路元素选择板中。只要复合电路对象将 C l o n e实现为一个深拷贝（deep copy），具有不同结构的电路就可以是原型了。
- 减少子类的构造 Factory Method（ 3 . 3）经常产生一个与产品类层次平行的 creater类层次。 Prototype模式使得你克隆一个原型而不是请求一个工厂方法去产生一个新的对象。因此你根本不需要Creater类层次。
- 用类动态配置应用 一些运行时刻环境允许你动态将类装载到应用中。
2.4.1 注意
我不知道到底有啥好处好继续研究
2.5 SINGLETON（ 单件） —对象创建型模式
2.5.1 意图
保证一个类仅有一个实例，并提供一个访问它的全局访问点。
2.5.2 结构图
2.5.3 使用场景
- 当类只能有一个实例而且客户可以从一个众所周知的访问点访问它时。
- 当这个唯一实例应该是通过子类化可扩展的，并且客户应该无需更改代码就能使用一个扩展的实例时
2.5.4 效果
- 对唯一实例的受控访问 因为 Singleton类封装它的唯一实例，所以它可以严格的控制客户怎样以及何时访问它。
- 缩小名空间 Singleton模式是对全局变量的一种改进。它避免了那些存储唯一实例的全局变量污染名空间。
- 允许对操作和表示的精化 Singleton类可以有子类，而且用这个扩展类的实例来配置一个应用是很容易的。你可以用你所需要的类的实例在运行时刻配置应用。
- 允许可变数目的实例 这个模式使得你易于改变你的想法，并允许 Singleton类的多个实例。此外，你可以用相同的方法来控制应用所使用的实例的数目。只有允许访问 Singleton实例的操作需要改变。
- 比类操作更灵活 另一种封装单件功能的方式是使用类操作（静态成员函数）。但这两种语言技术都难以改变设计以允许一个类有多个实例。此外， C++中的静态成员函数不是虚函数，因此子类不能多态的重定义它们
注意
没啥好好注意的，就是单例模式