行为型模式

目录

前言

之前总结了设计模式之创建型模式和结构型模式，现在汇总一下行为型模式。

观察者模式

观察者模式

定义了一种一对多的依赖关系，让多个观察者对象同事监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，是它们自动更新自己。

UML图

自己的理解

例子是当老板回来的时候，前台通知那些正在玩的同事老板回来了，该工作了。这个模式就是把涉及到所有人进行归类最后抽象出两大类，一个是抽象通知者，包括老板和前台，另一个是各种玩的同事。特点就在于老板，前台和同事这些具体类没有直接的接触，他们之间传递信息靠的是抽象类，比如在传状态的时候传的是抽象通知者的状态不是老板的也不是前台的，降低耦合性。

什么时候用：将一个系统分为好多相互协作的类，需要维护相关对象间的一致性，当一个对象改变时，需要改变其他对象，并且不知道有多少对象有待改变 ，使用观察者模式可以将这两者封装在独立的对象中使它们各自独立的改变和复用。

我想到了在VS中写代码，给一个对象改名字，会出来一个提示问你改不改，选择改之后，这个程序中所有这个对象的名字都会改，应该用的就是观察者模式。

模板方法模式

模板方法模式

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

UML图

自己的理解

这个模式的特点就是很好的实现代码的复用，把一些重复的不变的代码写到父类中，把需要发生变化的代码写到子类中，就像试卷例子中一样，试卷题和答案的规格样式都是一样的，唯一不一样就是学生的答案A B 还是C D，所以只把答案写到子类里，用一个虚方法来实现。

命令模式

命令模式（Command）

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

UML图

自己的理解

命令模式很好的实现了解耦，拿叫服务员点餐的例子来说，餐馆可以做好多菜肯定要写一个做菜的抽象类，下面是好多继承它的具体做菜类，必不可少需要一个厨师类，然而服务员类的出现使整个流程合理化并实现高效。

点餐前服务员通知顾客那些菜没有了，然后点餐也可以撤销已点的餐，还可以记录日志，如果餐馆想要添什么新菜样，直接加一些具体做菜的子类就好了，不用改动其他类，提高了扩展性，维护性，使代码变得灵活。

状态模式

状态模式（State）

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

UML图

自己的理解

例子是不同时间工作状态不同。当一个对象的行为及行为的改变取决于状态的时候就可以考虑状态模式了。

这些类中重要的就是有一个工作类，在工作类属性有时间，任务是否完成，动作有设置状态和写程序。一个抽象状态类和一些具体的状态类，每个类都有写程序的方法。客户端先实现工作类设置好初始时间和状态，然后调用工作类中的写程序方法，这个写程序方法就去众多具体状态类下的写程序方法中判断哪一个是符合这个时间的就调用哪个状态下的写程序方法。这样在客户端只有实例化工作类，调用工作类的方法，没有涉及到状态类，大大的降低了耦合性。

职责链模式

职责链模式（Chai of Responsibility）

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

UML图

自己的理解

上次万达老师讲今目标其实就是职责链模式，用今目标请假，我把信息填好，发给管我的纪委，他看看是请的几天的假，是否在他职责范围内，如果我请一年的假，他肯定批不了，就往上交，交给CEO，CEO也批不了就交给老师。在请假的这个链中我不知道谁给我的答复反正必须有人给我反馈，而且我只跟纪委打交道，解耦，我根本不用认识CEO 或老师就把假请了。

解释器模式

解释器模式（interpreter）

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

UML图

自己的理解

书上的例子是音乐解释器。我的理解是自己可以设定一套文法，当干什么事的 时候通过文法一翻译就是实现什么特定的功能。比如CSDN中的markdown编辑器，当你在几个字的两边加上#.. #的时候,就会变成一级标题。这个模式让我们自己去遍一些规则来实现我们想要的功能，创造力无限。

中介者模式

中介者模式（Mediator）

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

UML图

优点

Mediator的出现减少了各个college的耦合，使得可以独立地改变和复用各个college类和Mediator。由于把对象如何协作进行了抽象，将中介作为一个独立的概念并将其封装在一个对象中，这样关注的对象就从对象各自本身的行为转移到他们之间的交互上来，也是站在更宏观的角度去看待系统。

缺点

由于ConcreteMediator控制了集中化，于是就把交互复杂性变成了中介者的复杂性，这就使得中介者变得比任何一个ConcreteCollege都复杂。

自己的理解

中介者模式和代理模式有点相像，都是不让对象直接接触，不一样的是代理模式是找一个代理来代替一个对象去访问另一个对象，而中介模式是找一个中间人来管对象间的交互。代理模式就是一个好朋友替你追求男（女）朋友，而中介模式就是一个媒婆管中间的传话。

访问者模式

访问者模式（Visitor）

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

UML图

自己的理解

访问者模式和桥接模式有点类似。桥接模式是把抽象部分和实现部分分离，而访问者模式是把处理和数据结构分开。

桥接模式中是每个品牌下都有好多手机软件，这是静态的是一些事物间的关系，而访问者模式是男人和女人这相对固定的数据结构面临成功或失败时做出的反应，这个模式强调是动作，这也可能是为什么二者分别属于结构型和行为型模式的原因吧。

什么时候用：系统有比较稳定的数据结构，又有易于变化的算法，使用访问者模式比较合适。

优点：使增加新的操作很容易，将有关的行为集中到一个访问者对象中。

策略模式

策略模式（strategy）

它定义了算法家族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户。

UML图

自己的理解

策略模式用到的例子是商场促销有多重优惠方式，到底采用哪个方式，如果直接写到客户端，耦合性太强，也不好扩充和改变这些优惠方式，所以把这些优惠方式都封装一个策略里，收钱的时候计算单价乘以数量然后用上策略就行了，至于用粗略中的哪一个具体就在策略里加判断就行了。主题思想就是封装变化。

备忘录模式

备忘录（Memento）

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

UML图

自己的理解

涉及到的例子是游戏保存进度。UML图也很好理解，一个角色对象，拥有创建备忘录的功能，备忘录类就是保存角色对象的状态，再有一个管理者类保存备忘录。这个模式就是保存为了恢复用的，就像数据库中的日志一样。

什么时候用：备忘录模式比较适用于功能比较复杂的，但需要维护或记录属性历史的类，或者需要保存的属相知识众多属性中的一小部分是，对象可以根据备忘录的信息还原到前一状态。

迭代器模式

迭代器模式（Iterator）

提供一种方法顺序访问一个聚合对象中各个元素，而又不暴露该对象的内部表示。

UML图

自己的理解

迭代就是顺序，就是遍历。例子是公交车收费不漏掉任何一个人。迭代器模式就是分离了集合对象的遍历行为，抽象出一个迭代器类来负责，这样就可以做到不暴露集合的内部结构，又可让外部代码透明地访问集合内部的数据。

什么时候用：当需要对聚集有多种方式遍历时，可以考虑迭代器模式。

总结

设计模式三大类型主要是按目的进行区分的。创建模式关注对象的创建（是什么）；结构型模式关注类或对象之间的组织关系（什么关系）；行为型模式关注类或对象间的交互和职责分配（用来干什么）。

模式从本质上是分解化简类或对象，实现解耦，从而提高系统的可扩展性，可维护性，复用性和灵活性。