【设计模式】行为型模式

刺骨的言语ヽ痛彻心扉 2022-05-26 05:10 180阅读 0赞

我们已经知道，设计模式有23种：

<table> 
 <thead> 
  <tr> 
   <th>设计模式类型</th> 
   <th>包括</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>创建型模式 （5种）</td> 
   <td>单例模式、抽象工厂模式、建造者模式、工厂方法模式、原型模式</td> 
  </tr> 
  <tr> 
   <td>结构型模式（7种）</td> 
   <td>适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式</td> 
  </tr> 
  <tr> 
   <td>行为型模式 （11种）</td> 
   <td>模版方法模式、命令模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式（Interpreter模式）、状态模式、策略模式、职责链模式、访问者模式</td> 
  </tr> 
 </tbody> 
</table>

接下来对行为型模式进行一个详细的介绍和说明

<table> 
 <tbody> 
  <tr> 
   <td>模版方法模式：</td> 
  </tr> 
 </tbody> 
</table>

定义一个操作中算法的框架，而将一些步骤延迟到子类中。模板方法模式使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤

优点：
    1，在父类中定义一个算法，由它的子类来实现细节的处理
    2，模板方法是一种代码复用技术，可以将公共行为放在父类中
    3，可以通过子类来覆盖父类的基本方法
    缺点：
    需要为每一个基本方法的不同实现提供一个子类，如果父类中可变的基本方法太多，会导致系统更加庞大，降低系统性能

将一个请求封装为一个对象，从而让我们可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以及支持可撤销的操作。

优点：
    1，降低耦合度。因为请求者和接收者之间不存在引用，因为请求者和接收者之间是完全解耦的
    2，增加灵活性。由于增加新的具体命令类不会影响其他类，所以增加新的类时很容易
    3，可以比较容易的设计一个命令队列
    4，为请求的撤销和恢复操作提供了一种设计和实现方案
    缺点：
    可能会导致某些系统有过多的具体命令类。因为针对每一个请求接收者的调用操作都需要设计一个具体命令类

<table> 
 <tbody> 
  <tr> 
   <td>迭代器模式：</td> 
  </tr> 
 </tbody> 
</table>

提供一种方法来访问聚合对象，而不用暴露这个对象的内部表示

优点：
    1，支持以不同的方式遍历一个聚合对象
    2，简化了聚合类
    3，在迭代器模式中，增加新的聚合类和迭代器类都很方便，无须修改原有代码
    缺点：
    设计难度较大

<table> 
 <tbody> 
  <tr> 
   <td>观察者模式：</td> 
  </tr> 
 </tbody> 
</table>

定义对象之间的一种一对多依赖关系，使得每当一个对象状态发生改变时，其相关依赖对象皆得到通知并被自动更新

优点：
    1，可以实现表示层和数据逻辑层的分离
    2，在观察目标和观察者之间建立一个抽象的耦合
    3，支持广播通信
    4，增加新的具体观察者时，不需要修改原有系统代码
    缺点：
    1，如果一个观察目标对象有很多直接和间接观察者，将所有观察者都通知，会花费很多时间
    2，如果观察者和观察目标之间存在循环依赖，会导致循环调用，从而导致系统崩溃

<table> 
 <tbody> 
  <tr> 
   <td>中介者模式：</td> 
  </tr> 
 </tbody> 
</table>

用一个中介对象（中介者）来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互，是“迪米特法则”的一个典型应用

优点：
    简化了对象之间的交互，
    缺点：
    可能会导致中介者类非常复杂，使得系统难以维护

<table> 
 <tbody> 
  <tr> 
   <td>备忘录模式：</td> 
  </tr> 
 </tbody> 
</table>

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

优点：
    提供了一种状态恢复的机制
    缺点：
    资源消耗较大

<table> 
 <tbody> 
  <tr> 
   <td>解释器模式（Interpreter模式）：</td> 
  </tr> 
 </tbody> 
</table>

定义一个语言的文法，并且建立一个解释器来解释该语言中的句子，其中“语言”是指使用规定格式和语法的代码

优点：
    1，易于改变和扩展文法
    2，每一条文法规则都可以表示为一个类，因此可以方便的实现一个简单的语言
    3，增加新的解释表达式比较方便。如果用户需要增加新的解释表达式，只需要对应增加一个新的表达式即可，原有表达式类不需要做修改
    缺点：
    1，对于复杂文法难以维护。在解释器模式中，每一条规则至少需要定义一个类，因此如果一个语言包含太多文法规则，会导致系统难以管理和维护
    2，执行效率较低。由于在解释器模式中使用了大量的循环和递归调用，所以可能导致系统的执行效率变低

允许一个对象在其内部状态改变时改变它的行为，对象看起来似乎修改了它的类

优点：
    1，封装了状态的转换规则，可以对状态转换代码进行集中管理，而不是分散在一个个业务方法中
    2，将所有与某个状态有关的行为放到一个类中
    3，可以让多个环境对象共享一个状态对象
    缺点：
    1，状态模式使用，会导致系统运行开销增大
    2，状态模式如果使用不当，会增加系统设计难度

定义一系列算法类，将每一个算法封装起来，并让它们可以相互替换，策略模式让算法独立于使用它的客户而变化

优点：
    1，算法切换简单
    2，避免多重条件判断
    3，具有良好的扩展性
    缺点：
    1，客户端必须知道所有的策略类，并自行决定使用哪一个策略类。这就意味着客户端必须理解这些算法的区别，以便适时选择恰当的算法。换言之，策略模式只适用于客户端知道所有的算法或行为的情况。
    2，策略模式将造成系统产生很多具体策略类，任何细小的变化都将导致系统要增加一个新的具体策略类。
    3，无法同时在客户端使用多个策略类，也就是说，在使用策略模式时，客户端每次只能使用一个策略类，不支持使用一个策略类完成部分功能后再使用另一个策略类来完成剩余功能的情况。

<table> 
 <tbody> 
  <tr> 
   <td>职责链模式：</td> 
  </tr> 
 </tbody> 
</table>

避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。

优点：
    1，对象不需要知道是哪儿一个对象处理他的请求，只需要知道这个请求会被处理，从而降低了系统的耦合度
    2，增加灵活性，可以通过在运行时对该链进行动态的增加或修改来增加或改变处理一个请求的职责
    3，在系统中增加一个新的具体请求处理者时，不需要修改原有系统的代码，只需要在客户端重新建链即可
    缺点：
    1，由于一个请求没有明确的接受者，这个请求不一定会被处理
    2，对于比较长的职责链，可能涉及到多个处理对象，系统性能受到影响
    3，如果职责链建立的不是太合理，可能会造成循环调用，使系统陷入死循环

<table> 
 <tbody> 
  <tr> 
   <td>访问者模式：</td> 
  </tr> 
 </tbody> 
</table>

提供一个作用于某对象结构中的各元素的操作表示，它使我们可以在不改变各元素的类的前提下定义作用于这些元素的新操作

优点：
    1，增加新的访问操作很方便
    2，将有关元素对象的访问行为集中到一个访问者对象中，而不会分散在一个个的元素类中
    缺点：
    1，增加新的类很困难
    2，破坏封装

# 总结 #

到这里只是进行了一个简单的了解，在以后的过程中，还会再学习。  
感谢您的阅读~~