设计模式（下篇：行为型）

3.行为型

3.1 解释器模式

• 当一种问题/语言普遍化后，我们将它们用简单的形式表示 并 通过解释器 对应每个类/规则
• 易于拓展更改，难以管理维护
• 实际应用：
  Java和Class字节码的对应关系

3.2 迭代器模式

• 使用于不管什么对象都需要遍历时
• UML图
• 代码
  
  
  
  

3.3 中介者模式

• 像是联合国，房屋中介，处理双方之间的矛盾，是多对多的关系
  
• UML图
  
• 代码
  
  
  ConcreteColleague类
  
  
• 减少了Colleague的耦合，使得可以独立使用Meditor和Colleague各个类，但容易将交互复杂性转化为Meditor复杂性

3.4 访问者模式

• 把处理从数据结构中分离开来，使得不改变个元素的类，就能对元素进行新操作

• UML图
  （两个抽象类）
  

• 代码
  
  
  
  
  
  

• 适用于有比较稳定的数据结构，又有易于变化的算法

• 好处：
  易增加新操作
  不易改变数据结构

3.5 观察者模式

• 实际情景
  像是哨兵将信息给战斗的狙击手，司令员，值班士兵，并且不同角色给不同信息，是一种一对多的关系
• UML图
  
• 代码
  Subject类
  
  
  
  
  
• 该模式将一个系统分成了一系列需要相互合作的类，需维护了对象间的一致性
• 好处：抽象模型的两方面，该模式可将两者都依赖于抽象，而不是具体，一方变另一方不会受影响

3.6 状态模式

• 当一个对象内在状态改变时，允许改变其行为，看起来好像改变了其类
• UML图
  
• 代码
  
  
  
  

3.7 策略模式

• 简单工厂模式的升级版：
  将 相同属性和功能的对象抽象集合起来
  
  Strategy实现Context，具体Strategy继承抽象
  Stragety层为Context定义了一系列可供重用的算法和行为，析取出公共功能
• 具体代码

• 适用于完成相同工作，实现不同
• 升级版：使用反射，后续更新

3.8 备忘录模式

• 实际场景：退出后，游戏状态的保存
• 不破坏封装性，在对象之外保存对象内部状态
• UML图
  
• 代码
  
  
  

3.9 责任链模式

• 实际情景：要跟老板申请加薪，要通过经理，总监再到总经理

• 将提出请求的对象连成一条链，按照链传递该请求，直到有一个对象处理它，并防止请求最后也不能被处理

• 职责链可简化对象间的连接，仅需保持一个对后继者的引用即可

• UML图

• 代码
  
  

• 单一职责，减少耦合

3.10 命令模式

（像是烤肉店和烤肉摊，前者有服务员，后者只行为请求者和实现者紧耦合）

• UML图
  
• 代码
  
  
  
  
  
• 容易对请求进行撤销和重做，不影响其他类

3.11 模板方法

• 定义一个骨架，将一些步骤延迟到子类中
• UML图
  
• 代码
  
  
  
• 特点
  将不变的行为移到超类，去除子类中重复代码，提供了一个代码复用平台

---

最后

行为型模式有
1.策略方法：提出抽象算法类，子类是具体算法，区别于抽象工厂· ；
2.中介者：提供一对多的接口，降低耦合，但可能导致Meditor复杂，如MVC；
3.观察者：从类的角度一对多，对象的角度可多对多，起到通知改变作用；
4.模板方法：提供骨架，即代码复用平台；
5.备忘录：对象外保存对象内部状态；
6.解释器：不同于“适配器”，该模式是将 简单问题的表示形式 转化为 具体操作；
7.迭代器：对象循环遍历时使用；
8.责任链：提出请求的对象在一条链上依次提交，直到请求被处理
9.状态：在对象内部进行的状态改变
10.访问者：把处理从数据结构中分离开来
11.命令：类似餐馆中 服务员负责菜单内容和增删改查操作，以降低耦合