设计模式大杂烩之三

        设计模式大杂烩之二介绍了结构型设计模式，接下来介绍行为型模式。行为型模式对类或对象怎样交互和怎样分配职责进行描述。与结构型设计模式分类一样，行为型模式分为行为型类模式和行为型对象模式。行为型类模式使用继承描述算法和控制流，而行为型对象模式则描述一组对象怎样协作完成单个对象所无法完成的任务。属于行为型类模式的有解释器（Interpreter）和模板方法（Template Method），属于行为型对象模式的有职责链(chain of  responsibility)、命令(command)、迭代器(iterator)、中介者（mediator）、备忘录（memento）、观察者（observer）、状态（state）、策略(strategy)和访问者（visitor）。

         首先介绍行为型类模式。解释器设计模式的目的是为了处理给定一个语言，定义它的文法（规则）的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。对于一种特定类型的问题发生频率足够高，那么值得将该问题的各个实例表述为一个简单语言中的句子。解释器模式使用类来表示每一条文法规则，每个文法定义都表示为一个由这些类的实例构成的抽象语法树。该模式由3部分构成，Context、抽象解释操作接口和抽象解释操作接口具体实现，定义一个抽象解释作接口，该接口为抽象语法树所有实现类的共同接口，该接口接收上下文对象作为要解释对象。模板方法模式的目的是为了定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法模式使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤具体实现。面向对象抽象的是共性，特性可以在子类型或具体实例中加以区分，这样可以实现最大复用和维护最简便，因为共性就意味着相同和集中，假如共性部分发生改变，那么仅仅在共性地方修改，使用共性部分都可以得到更新。该模式由一个公共接口（抽象类）和公共接口具体实现类型组成，该接口提供一个公共对外接口（public）和多个步骤的抽象定义，这个接口里面逐个调用算法实现步骤（protected），这样这些算法步骤只能在包内或子类中可以进行定义。模板方法是一种代码复用的基本技术，在类库中尤为重要，它们提取了类库中饿公共行为，模板方法导致了一种反向的控制结构——父类调用一个子类的操作。

        其次介绍行为性对象模式。职责链模式的目的是为了是多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。正常情况下，假如请求的发送者与接收者是一对一关系，那么发送者可以直接获取接收者进行调用，但是当请求在不同状态下会有不一样的处理实现时，那么就变成是一对多的关系了，此时需要额外的接口暴露给发送者获取接收者数组或者硬编码固定接收者，接收者数组的方式虽然可以避免发送者与数组的耦合关系，但是不得不提供另外获取接收者数组的接口，当程序存在多个这样的情况，那么这一类接口数量会十分多，有时候还会较难理解，例如为了维护方便，一对一也提供这样的接口，不然就要改变发送者实现了。而使用职责链模式，发送者与接收者之间的一对多请求关系就跟一对一请求一样，职责链提供一个统一的接收者入口而不需要提供额外的接口。职责链模式包括两部分，一部分是请求处理接口，一部分是请求处理接口具体实现，其中请求处理具体实现中维护另一个请求处理接口实现引用。命令模式的目的是将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化。有时必须向某对象提交请求，但并不知道关于被请求的操作或请求的接收者的任何信息。通过将请求封装成共同接口的类型，可以将请求对象传递给请求接收者，接收者通过请求公共接口进行调用，实际上接收者内部的请求实现是空的。命令模式由4部分组成，Command执行操作公共接口、Command具体实现类、调用者invoker和接收者Receiver，接收者可以是任何类，创建Command对象是制定接收者，然后使用invoker对象存储Command对象，invoker通过调用Command对象的execute操作来提交一个请求，Command对象调用它的receiver的操作以执行该请求。迭代器模式的目的是提供一种方法顺序访问一个聚合对象中各个元素，而又不需暴露该对象的内部表示。它的关键思想是将对聚合对象的访问和遍历从聚合对象中分离出来并放入一个迭代器对象中，迭代器类定义了一个访问该聚合元素的接口，迭代器负责跟踪当前的元素。它由4部分组成，聚合接口、聚合接口具体实现、迭代器接口和迭代器具体实现，其中聚合接口中包含创建相应迭代器的接口。中介者模式的目的是用一个中间对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。面向对象设计鼓励将行为分布到各个对象中，这样通常可以增强可复用性，但是这种分布可能会导致对象间可能会有许多连接，连接激增又会降低其可复用性，互相连接将它们表现为一个不可分割的整体。中介者模式将集体行为封装在一个单独的中介者对象中，中介者负责控制和协调一组对象间的交互。中介者充当一个中介以使组中的对象不再互相显示引用。这些对象仅仅知道中介者，从而减少互相连接的数目。中介者模式由4部分组成，中介者接口、中介者具体实现、需要互相连接的组对象接口和组对象具体实现类。备忘录模式的目的是在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样以后就可以将该对象恢复到原先保存的状态。为了允许用户取消不确定的操作或从错误中恢复过来，需要实现检查点和取消机制，要实现这些机制，必须事先将状态信息保存在某处，但对象通畅封装了其部分或所有的状态信息也就不能在该对象之外保存其状态，而暴露内部状态又将违反封装原则，有损可靠性和可拓展性。备忘录模式由3部分组成，Memento（备忘录）、Originator（原发器）和Caretaker（负责人），负责人向原发器请求一个备忘录，原发器创建备忘录对象，设置备忘录状态，负责人可以获取之前保存的备忘录状态。备忘录实际上有两个接口，负责人（caretaker）只能看到备忘录的窄接口——它只能将备忘录传递给其他对象，原发器能够看到一个宽接口，允许它访问返回到先前状态所需的所有数据。观察着模式的目的是为了定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。将一个系统分割成衣系列相互协作的有一个常见的副作用：需要维护相关对象间的一致性。观察者模式描述了目标和观察者对象间一致性问题，一个目标可以有任意数目的依赖它的观察者，一旦目标的状态发生改变，所有的观察者都得到通知，这种交互也称发布-订阅，目标是通知的发布者，它发出通知时并不需要知道谁是它的观察者。观察者模式由4部分组成，目标接口、目标具体实现、观察者接口和观察者具体实现，目标接口有3个请求，添加观察者请求、移除观察者请求和通知请求，观察者接口主要有一个请求，处理通知请求。状态模式的目的是允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。状态模式由3部分组成，Context（环境）、State（状态）接口和状态具体实现，Context维护State具体实现的实例，State接口定义一个接口以封装与Context的一个特定状态相关的行为。策略模式的目的是定义一系列的算法，把它们一个个封装起来并且使它们可相互替换。本模式使得算法可独立于使用它的客户变化。策略模式与状态模式十分类似，不过是目的驱动上不类似，状态模式中状态改变就修改对象行为，而策略模式是客户将算法请求传递给具体策略实例。组成上有Context、Strategy（策略）接口和具体策略实现，当算法被调用时，Context可以将该算法所需要的所有数据都传递给该Strategy。访问者模式的目的是表示一个作用域某对象结构中的各元素的操作。它使你可以再不改变个元素的类的前提下定义作用于这些元素的新操作。要使用访问者模式，必须定义两个类层次，一个对应于接受操作的元素，另一个对应于定义对元素的操作的访问者。在这里需要重新提一下装饰器模式——动态给一个对象添加额外的职责，而访问者模式是在不修改结构中各元素所在的类的情况下，增加处理结构各元素的新操作，装饰器针对的是自身，访问者针对的是对象中增加处理元素的操作。访问者模式由5个部分组成，Visitor（访问者）接口、具体访问者实现、Element（元素）接口、具体元素实现和对象结构，其中访问者接口实现接收元素作为参数，以便在访问者实现里面操作元素。

        设计模式大杂烩介绍已经完毕，由于篇幅和认识有限，后续将会对每个设计模式进行深入讨论。