设计模式总结

设计模式总结

Creational patterns 创建型模式
Structural patterns 结构型模式
Behavioral patterns 行为类模式

一、创建型模式
1）factory method工厂方法模式
当client不知道要创建哪个具体类的实例，或者不想在client代码中指明要具体 创建的实例时，用工厂方法。
定义一个用于创建对象的接口，让其子类来决定实例化哪一个类，从而使一个 类的实例化延迟到其子类。

Client使用 “工厂方法” 来创建实例， 得到实例的类型是抽象接口 而非具体类

2）abstract factory抽象工厂模式
一个UI， 包含多个窗口控件，这些控件在不同的OS中实现不同
一个仓库 类，要控制多个设备，这些设备的制造商各有不同，控制接口有差异
抽象工厂模式：提供接口以创建一组相关/相互依赖的对象， 但不需要指明其具体类。

创建的不是一个完整产品，而是“产品族”（遵循 固定搭配规则的多类产品的实例），得到的结果是：多个不同产品的 object，各产品创建过程对client可见，但“搭配”不能改变。  本质上，Abstract Factory是把多类产品的factory method组合在一起

二、结构型模式
适配器允许具有不兼容接口的类一起工作，方法是将自己的接口包装在已存在类的接口周围。
Decorator在对象的现有方法中动态添加/重写行为。
Facade为大量代码提供了一个简化的接口。

1）adapter适配器模式
将某个类/接口转换为client期望的其他形式
通过增加一个接口，将已存在 的子类封装起来，client面向接口编程，从而隐藏了具体子类。


2）decorator装饰器模式

UndoStack：允许您撤消以前的push或pop操作的堆栈
SecureStack：需要密码的堆栈
SynchronizedStack：序列化并发访问的堆栈
用每个子类实现不同的特性

以及任意组合的扩展：
SecureUndoStack：需要密码的堆栈，还允许您撤消以前的操作
SynchronizedUndoStack：序列化并发访问的堆栈，还允许您撤消以前的操作
等


3) Facade外观模式
我们假设使用MySql等不同类型的应用程序生成报表。
因此，我们将有不同的接口集来处理不同类型的数据库。
现在，客户机应用程序可以使用这些接口来获得所需的数据库连接并生成报告。
但是，当复杂性增加或接口行为名称令人困惑时，客户端应用程序将发现很难管理它。
所以我们可以在这里应用Facade模式，并在现有接口的基础上提供一个包装器接口来帮助客户机应用程序。


4）proxy代理模式
某个对象比较“敏感”/“私密”/“贵重”，不希望被client直接访问 到，故设置proxy，在二者之间建立防火墙。

作用：
隔离对复杂 对象的访问，降低难度/代价，定位在“访问/使用行为”

与适配器的区别，适配器的作用：
消除不兼容，目的是B以客户端期望的统一的方式与A建立起联系。

三、行为类模式
1）Strategy策略模式
有多种不同的算法来实现同一个任务，但需要client根据需要动态切换算法，而不是写死在代码里
示例：对客户列表排序（气泡排序、合并排序、快速排序）
为不同的实现算法构造抽象接口，利用delegation，运行时动态传入client倾向的算法类实例
优势：
易于扩展新算法实现
将算法与客户端上下文分离

2) Template Method模板模式

问题：多个客户端共享相同的算法，但在具体细节上有所不同，即算法由可定制部分和不变部分组成。公共步骤不应在子类中重复，但需要重用。
做事情的步骤一样，但具体方法不同
示例：
执行测试用例的测试套件
打开、阅读、书写不同类型的文件
解决方案：
-共性的步骤在抽象类内公共实现，差异化的步骤在各个子类中实现
-子类为每个步骤提供了不同的实现。
使用继承和重写实现模板模式

3）terator迭代器模式
客户端希望遍历被放入 容器/集合类的一组ADT对象，无需关心容器的具体类型也就是说，不管对象被放进哪里，都应该提供同样的遍历方式
解决方案：迭代的策略模式
后果：
隐藏内部容器的底层实现
支持统一接口的多种遍历策略
易于更换容器类型
促进程序各部分之间的通信


4）Observer观察者模式
问题：从属的状态必须与主控形状的状态一致
解决方案：定义四种对象：
抽象主题：维护从属列表；当主控形状更改时通知它们
抽象观察者：定义更新依赖项的协议
具体主题：管理从属项的数据；在主控形状更改时通知他们
具体观察者：在收到更新消息时获取新的主题状态

5）visitor访问者模式
对特定类型的object的特定操作(visit)，在运行时将 二者动态绑定到一起，该操作可以灵活更改，无需更改被visit的类
本质上：将数据和作用于数据上的某种/些特定操作分离开来。
为ADT预留一个将来可扩展功能的“接入点”，外部实现的功能代码 可以在不改变ADT本身的情况下通过delegation接入ADT

6）State Pattern状态模式
假设一个对象总是处于几种已知状态之一
对象所处的状态决定了几种方法的行为
可以在每个方法中使用if/case语句

具有对状态对象的引用
通常，状态对象不包含任何字段
更改状态：更改状态对象
方法委托给状态对象

最好不要使用if/else 结构在ADT内部实现 状态转换（考虑将来的 扩展和修改）
使用delegation，将状 态转换的行为委派到独 立的state对象去完成





7）Memento Pattern备忘录模式
意图
在不违反封装的情况下，捕获并外部化对象的内部状态，以便以后可以将对象返回到此状态。 封装“检查点”功能的神奇cookie。
将撤消或回滚升级到完全对象状态。
问题：需要将对象恢复到以前的状态（例如“撤消”或“回滚”操作）。

需要“备忘”的类
添加originator的备忘记录和恢复
备忘录，记录originator对象的历史状态
需要“备份”的 ADT，完全可以 自己增加方法来支持备份