【Adapter 模式】
其实就是一种 组合。把两个没有关系的 API 组合在一起，然后公开一个混合接口（混血儿） API。
例如有组件A和组件B，现在要设计一个类 C，综合运用 A 和 B。那么 C 就是适配器，A 和 B 就是被适配的物件。
首先让 A 和 B 都 implements interface A' 和 interface B' ，然后让 C implements A' 和 B'。接下来有两种方案。
一种方案是没有反射探测的。首先在 C 里设定两个 private instance 分别对应 A 和 B，然后设定两个分别对应 A 和 B 的注入式构造器，在 execute() 方法体里 hard-code 指定地调用 A 或者 B 的方法。
另一种方案是利用反射探测的，名为 Plugable Adapter。构造器注入 A 或者 B，然后 execute 调用 A 或者 B 的方法。但是这样是不是应该让 A 和 B 都 implements 同一个 interface 呢？
【Builder 模式】
其实是 指导装配 。
需要一个 构建者 Builder 接口、一个 实例构建者 BuilderImpl 类 和一个 装配指导者 Director 类。
BuilderImpl implements Builder
Director 类的注入式构造器注入一个 Builder 接口，意思是可以灵活指定不同的 实例构建者。
构建者接口定义了多个部件生成器行为，实例构建者是这些行为的具体实现。
装配指导者通过按 [指定的顺序] 调用构建者的行为（实际上是调用了实例构建者的行为内容），以达到装配的目的。
【Composite 模式】
这是一种更强大也比较复杂的 组合应用。
它假定一些相似的物件为“设备”，另一些可容纳“设备”的物件为“设备箱子”。
“设备”和“设备箱子”都继承自抽象类“物件”。物件中除了有注入物件名称的构造器、抽象的公共属性外，还有一个返回 Iterator 对象的 iter() 方法，用以遍历并返回全体 child 设备。
只有“设备箱子”需要实现 iter() 方法。因此“设备箱子”有一个私有的列表对象用以存放 child 设备，以及一个私有指针属性用以指示列表的当前位置。
顶层元素是一个“设备箱子”，它可以容纳多个“设备”和多个“child 设备箱子”，由此形成一个以“设备”为单元的树状结构。
“设备”拥有一些公共属性，例如价格、净重。“设备箱子”也拥有这些公共属性，不同的是“设备箱子”的价格、净重是通过使用 Iterator 统计箱子里所有“设备”的价格、净重所得到的合计数值。
所以在查看一个“设备箱子”的价格、净重的时候，其实是查看了一个迭代统计的结果。
Composite 的意义是“想到Composite就应该想到树形结构图。组合体内这些对象都有共同接口,当组合体一个对象的方法被调用执行时，Composite将遍历(Iterator)整个树形结构,寻找同样包含这个方法的对象并实现调用执行。可以用牵一动百来形容。”
说到底，Composite 模式使“设备箱子”具有了访问“child 设备”的一些方法。
【Bridge 模式】
解决的是某种抽象物件具有多种具备交叉特性的实现形式的问题。
例如，抽象物件是“咖啡”，假定有如下四种实现形式：
1. 加奶中杯
2. 不加奶中杯
3. 加奶大杯
4. 不加奶大杯
所谓的“Bridge”，其意义实际上相当于电路连接中的“桥接”电路。
加不加奶是一种特性 [品质]，容器大小是另一种特性 [容量]。为了解决这种交叉特性的问题，需要使用“桥接模式”。
首先定义一个抽象类“咖啡”，它拥有一个私有对象属性“咖啡品质”以及它的 getter & setter。还有一个抽象方法“冲咖啡”。
然后定义一个抽象类“咖啡品质”，它拥有一个抽象方法“冲XX品质的咖啡”。
设定两个实现类：“加奶咖啡”和“纯咖啡”，继承自“咖啡品质”，填写“冲xx品质的咖啡”方法的内容。（例如传递一些特征信息来表示 [品质] 特性：“加了美味的牛奶”和“什么也没加，清香”）
设定两个另实现类：“中杯咖啡”和“大杯咖啡”，继承自“咖啡”。在它们的注入式构造器中注入“咖啡品质”，然后实现“冲咖啡”方法。（例如使用重复冲入的次数来表征 [容量] 特性，2次表示中杯，5 次表示大杯）
最后，通过构造一个“大杯咖啡”，并在构造时注入一个“加奶咖啡”，然后使用“冲咖啡”方法，得到一杯“加奶大杯咖啡”。
[看起来有点废....]
【Flyweight 享元模式】
这是一种把完全相同的对象/属性对象归结为一个对象，以解决重复消耗无谓内存、提高性能的方法。
简单点说，就是做一个“池”来存放对象的唯一实例。
假定用计算机模拟一个游戏战场，战场上有1000个作战单位，其中有 5000 个完全相同的车轮、500门50mm加农炮。假定它们没有磨损指标属性，要不存在要不不存在。
如果创建 5000 个车轮对象、500 个加农炮对象，必然比创建 1 个车轮对象、1 个加农炮对象多消耗 n 倍内存。
那么，创建一个存放设备的 Hashtable，需要时按照 keyname 从设备 hashtable 中提取某种设备的实例对象，如果池中不存在该种设备的实例对象，则添加（add）这个实例进入 hashtable。
只要是 keyname 相同的，就提取同一个实例供使用。 通常结合 factory 使用。
在一个类的实例对象中，若需要使用某个固定内容的属性，则使用享元模式（结合 factory）实现之。
其实就是一种 组合。把两个没有关系的 API 组合在一起，然后公开一个混合接口（混血儿） API。
例如有组件A和组件B，现在要设计一个类 C，综合运用 A 和 B。那么 C 就是适配器，A 和 B 就是被适配的物件。
首先让 A 和 B 都 implements interface A' 和 interface B' ，然后让 C implements A' 和 B'。接下来有两种方案。
一种方案是没有反射探测的。首先在 C 里设定两个 private instance 分别对应 A 和 B，然后设定两个分别对应 A 和 B 的注入式构造器，在 execute() 方法体里 hard-code 指定地调用 A 或者 B 的方法。
另一种方案是利用反射探测的，名为 Plugable Adapter。构造器注入 A 或者 B，然后 execute 调用 A 或者 B 的方法。但是这样是不是应该让 A 和 B 都 implements 同一个 interface 呢？
【Builder 模式】
其实是 指导装配 。
需要一个 构建者 Builder 接口、一个 实例构建者 BuilderImpl 类 和一个 装配指导者 Director 类。
BuilderImpl implements Builder
Director 类的注入式构造器注入一个 Builder 接口，意思是可以灵活指定不同的 实例构建者。
构建者接口定义了多个部件生成器行为，实例构建者是这些行为的具体实现。
装配指导者通过按 [指定的顺序] 调用构建者的行为（实际上是调用了实例构建者的行为内容），以达到装配的目的。
【Composite 模式】
这是一种更强大也比较复杂的 组合应用。
它假定一些相似的物件为“设备”，另一些可容纳“设备”的物件为“设备箱子”。
“设备”和“设备箱子”都继承自抽象类“物件”。物件中除了有注入物件名称的构造器、抽象的公共属性外，还有一个返回 Iterator 对象的 iter() 方法，用以遍历并返回全体 child 设备。
只有“设备箱子”需要实现 iter() 方法。因此“设备箱子”有一个私有的列表对象用以存放 child 设备，以及一个私有指针属性用以指示列表的当前位置。
顶层元素是一个“设备箱子”，它可以容纳多个“设备”和多个“child 设备箱子”，由此形成一个以“设备”为单元的树状结构。
“设备”拥有一些公共属性，例如价格、净重。“设备箱子”也拥有这些公共属性，不同的是“设备箱子”的价格、净重是通过使用 Iterator 统计箱子里所有“设备”的价格、净重所得到的合计数值。
所以在查看一个“设备箱子”的价格、净重的时候，其实是查看了一个迭代统计的结果。
Composite 的意义是“想到Composite就应该想到树形结构图。组合体内这些对象都有共同接口,当组合体一个对象的方法被调用执行时，Composite将遍历(Iterator)整个树形结构,寻找同样包含这个方法的对象并实现调用执行。可以用牵一动百来形容。”
说到底，Composite 模式使“设备箱子”具有了访问“child 设备”的一些方法。
【Bridge 模式】
解决的是某种抽象物件具有多种具备交叉特性的实现形式的问题。
例如，抽象物件是“咖啡”，假定有如下四种实现形式：
1. 加奶中杯
2. 不加奶中杯
3. 加奶大杯
4. 不加奶大杯
所谓的“Bridge”，其意义实际上相当于电路连接中的“桥接”电路。
加不加奶是一种特性 [品质]，容器大小是另一种特性 [容量]。为了解决这种交叉特性的问题，需要使用“桥接模式”。
首先定义一个抽象类“咖啡”，它拥有一个私有对象属性“咖啡品质”以及它的 getter & setter。还有一个抽象方法“冲咖啡”。
然后定义一个抽象类“咖啡品质”，它拥有一个抽象方法“冲XX品质的咖啡”。
设定两个实现类：“加奶咖啡”和“纯咖啡”，继承自“咖啡品质”，填写“冲xx品质的咖啡”方法的内容。（例如传递一些特征信息来表示 [品质] 特性：“加了美味的牛奶”和“什么也没加，清香”）
设定两个另实现类：“中杯咖啡”和“大杯咖啡”，继承自“咖啡”。在它们的注入式构造器中注入“咖啡品质”，然后实现“冲咖啡”方法。（例如使用重复冲入的次数来表征 [容量] 特性，2次表示中杯，5 次表示大杯）
最后，通过构造一个“大杯咖啡”，并在构造时注入一个“加奶咖啡”，然后使用“冲咖啡”方法，得到一杯“加奶大杯咖啡”。
[看起来有点废....]
【Flyweight 享元模式】
这是一种把完全相同的对象/属性对象归结为一个对象，以解决重复消耗无谓内存、提高性能的方法。
简单点说，就是做一个“池”来存放对象的唯一实例。
假定用计算机模拟一个游戏战场，战场上有1000个作战单位，其中有 5000 个完全相同的车轮、500门50mm加农炮。假定它们没有磨损指标属性，要不存在要不不存在。
如果创建 5000 个车轮对象、500 个加农炮对象，必然比创建 1 个车轮对象、1 个加农炮对象多消耗 n 倍内存。
那么，创建一个存放设备的 Hashtable，需要时按照 keyname 从设备 hashtable 中提取某种设备的实例对象，如果池中不存在该种设备的实例对象，则添加（add）这个实例进入 hashtable。
只要是 keyname 相同的，就提取同一个实例供使用。 通常结合 factory 使用。
在一个类的实例对象中，若需要使用某个固定内容的属性，则使用享元模式（结合 factory）实现之。
浙公网安备 33010602011771号