行为型模式（二）

不念不忘少年蓝@ 2022-05-23 09:50 64阅读 0赞

*上接行为型模式（一）*

##  状态模式 ##

当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。

实例：在公司一天的状态  
  ![这里写图片描述][70]  
  优点：把状态的判断逻辑转移到表示不同状态的一系列类当中，可以把复杂的判断逻辑简化；将与特定状态相关的行为局部化，并且将不同状态的行为分割开来；消除庞大的条件分支语句，减少相互之间的依赖；

缺点：增加系统中类的个数；若使用不当会导致程序结构或代码的混乱；

适用场景：当控制一个对象状态转换的条件表达式过于复杂，依靠大量的多分支判断语句来实现；当一个对象的行为取决于他的状态，并且它必须在运行时刻根据状态改变他的行为时；

##  备忘录模式 ##

在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。

实例：游戏回到之前  
  ![这里写图片描述][70 1]  
  优点：当角色的状态改变时，有可能这个状态无效，就可以使用暂时存储起来的备忘录将状态复原；实现了对信息的封装；

缺点：角色状态需完整存储到备忘录对象中，如果状态数据很大很多，会非常耗内存；

适用场景：功能比较复杂的，但需要维护或记录属性历史的类，或需要保存的属性只是众多属性中的一小部分；防止外界对象破坏一个对象历史状态的封装性，避免将对象历史状态的实现细节暴露给外界对象；

##  职责链模式 ##

使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。

实例：小菜加薪  
  ![这里写图片描述][70 2]  
  优点：不影响客户端的情况下动态地重新组织和分配责任；当客户提交一个请求时，请求是沿链传递直至由一个对象负责处理它，请求者不用管哪个对象来处理；降低耦合度，增加了给对象指派职责的灵活性；

缺点：一个请求极有可能到了链的末端都得不到处理，或者因为没有正确配置而得不到处理；

适用场景：有多个对象可以处理同一个请求；在不明确指定接收者的情况下；动态指定对象处理请求；

##  中介者模式 ##

用一个中介对象来封装一系列的对象的交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变他们之间的交互。

实例：联合国的作用  
  ![这里写图片描述][70 3]  
  优点：减少耦合；由于把对象如何协作进行了抽象，将中介作为一个独立的概念并将其封装在一个对象中，这样关注的对象就从对象各自本身的行为转移到他们之间的交互上来，也就是站在一个更宏观的角度去看待系统；

缺点：交互复杂性变成中介者复杂性，使得中介者会变得很复杂；

适用场景：一组对象以定义良好但是复杂的方式进行通信的场合；想定制一个分布在多个类中的行为，而又不想生成太多的子类的场合；

##  解释器模式 ##

给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。

实例：音乐解释器  
  ![这里写图片描述][70 4]  
  优点：很容易地改变和扩展文法，因为该模式使用类来表示文法规则，你可使用继承来改变或扩展该文法。也比较容易实现文法，因为定义抽象语法树中各个节点类的实现大体类似，这些类都易于直接编写；

缺点：为文法中的每一条规则至少定义了一个类，因此包含许多规则的文法可能难以维护和管理。

适用场景：如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子；当有一个语言需要解释执行，并且你可将该语言中的句子表示为一个抽象语法树时；

# 总结 #

行为型模式关注的是对象的行为问题，如果对象的行为设计的好，那么对象的行为就会更清晰，之间的效率就会更高。

[70]: /images/20220523/194789e66e474c7e85302346cffa5c8d.png
[70 1]: /images/20220523/e884cc482ece47d689f120af4a9bc4f0.png
[70 2]: /images/20220523/3d42b65f767a4f43add1935ead09c000.png
[70 3]: /images/20220523/80797a3af753464694757344d5db43ee.png
[70 4]: /images/20220523/0d960bf4de9648c6acd3f481664c2d8a.png