行为型模式
行为型模式
一、Template Method模板方法
《设计模式之禅》中，定义了Template Method pattern ，定义一个操作中的算法的框架
而将一些步骤延迟到子类中。使得子类可以不改变一个算法的结构即可重定义该算法的某些步骤。仅仅使用了Java继承机制，却应用广泛。
其优点是：封装不变部分，扩展可变部分。
提取公共部分代码，便于维护。
行为由父类控制，子类实现。
《C#面向对象设计模式纵横谈》中写到，变化——是软件设计的永恒主题，设计模式的艺术性和复杂度就在于如何分析，并发现系统中的变化点和稳定点，并使用特定的设计方法来应对这种变化。
其中，Template Method模式是一种非常基础性的设计模式，在面向对象系统中有着大量的应用。它用最简洁的机制（虚函数的多态性）为很多应用程序框架提供了灵活的扩展点，是代码复用方面的基本实现结构。
它除了可以灵活应对子步骤的变化外，“不要调用我，让我来调用你”的反向控制结构是Template Method的典型应用。
在具体实现方面，被Template Method调用的虚方法可以具有实现，也可以没有任何实现（抽象方法、纯虚方法），但一般推荐将它们设置为protected方法。
二、Command 命令
我们可以从《C#面向对象设计模式纵横谈》中了解到，耦合是软件不能抵御变化灾难的根本性原因。不仅实体对象与实体对象之间存在耦合关系，实体对象与行为操作之间也存在耦合关系。
而Command模式的根本目的在于将“行为请求者”与“行为实现者” 解耦，在面向对象语言中，常见的实现手段是“将行 为抽象为对象”。
实现Command接口的具体命令对象ConcreteCommand有时候根据需要可能会保存一些额外的状态信息。
而且通过使用Composite模式，可以将多个“命令”封装为一个“复令”MacroCommand。
Command模式与C#中的Delegate有些类似。但两者定义 行为接口的规范有所区别Command以面向对象中的“接口-实现”来定义行为接口规范，更严格，更符合抽象原
则；
Delegate以函数签名来定义行为接口规范，更灵活， 但抽象能力比较弱。
《设计模式之禅》中，定义了将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，
以及支持可撤销的操作。可分为，Receive接收者角色、Command命令角色、Invoker调用者角色。
三、Interpreter 解释器
《C#面向对象设计模式纵横谈》中谈到Interpreter模式的应用场合是Interpreter模式应用中的难点，只有满足“业务规则频繁变化，且类似的模式不断重复出现，并且容易抽象为语法规则的问题”才适合使用Interpreter模式。
应使用Interpreter模式来表示文法规则，从而可以使用面向对象技巧来方便地“扩展”文法。还有Interpreter模式比较适合简单的文法表示，对于复杂的文法表示，Interperter模式会产生比较大的类层次结构，需要求助于语法分析生成器这样的标准工具。
《设计模式之禅》中定义，给定一个语言，定义它的文法的一种表示，并定义一种解释器，这个解释器使用该表示来解释语言中的句子。
四、Mediator 中介者
当将多个对象间复杂的关联关系解耦，Mediator模式将多个对象间的控制逻辑进行集中管理，变“多个对象互相关联”为“多个对象和一个中介者关联”，简化了系统的维护，抵御了可能的变化。随着控制逻辑的复杂化，Mediator具体对象的实现可能相当复杂。这时候可以对Mediator对象进行分解处理。
Façade模式是解耦系统外到系统内（单向）的对象关联关系；
Mediator模式是解耦系统内各个对象之间（双向）的关联关系。
《设计模式之禅》中提到，我们可以根据业务的要求生产多个中介者，并划分各个中介者的职责。
定义：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式的相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
这里的中介模式分为三类：Mediator抽象中介者
Concrete Mediator具体中介者
Colleague同事中介者
五、Iterator 迭代器
迭代抽象：访问一个聚合对象的内容而无需暴露它的内部表示。
迭代多态：为遍历不同的集合结构提供一个统一的接口，从而支持同样的算法在不同的集合结构上进行操作。
迭代器的健壮性考虑：遍历的同时更改迭代器所在的集合结构，会导致问题。
《设计模式之禅》中提到，Iterator 迭代器提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露该对象的内部表示。Iterator 迭代器是为容器服务的。例如，collection集合类型、set类型等。
六、Observer 观察者
纵横谈中讲到，在软件构建过程中，我们需要为某些对象建立一种“通知依赖关系” ——一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知。如果这样的依赖关系过于紧密，将使软件不能很好地抵御变化。使用面向对象技术，可以将这种依赖关系弱化，并形成一种稳定的依赖关系。从而实现软件体系结构的松耦合。
在使用面向对象的抽象的同时，Observer模式使得我们可以独立地改变目标与观察者，从而使二者之间的依赖关系达致松耦合。
当目标发送通知时，无需指定观察者，通知（可以携带通知信息作为参数）会自动传播。观察者自己决定是否需要订阅通知，目标对象对此一无所知。
而在C#的event中，委托充当了抽象的Observer接口，而提供事件的对象充当了目标对象。委托是比抽象Observer接口更为松耦合的设计。
《设计模式之禅》中定义对象间的一种一对多的依赖关系，以便当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并自动更新。
七、Chain of Responsibility 职责链
就是请求的发送者和接收者，一个请求发送者可能有多个请求接收者。但是每个请求在运行时只能有一个接受者，如果显式指定，将必不可少地带来请求发送者与接受者的紧耦合。
其中，Chain of Responsibility 模式的应用场合在于“一个请求可能有多个接受者，但是最后真正的接受者只有一个”，只有这时候请求发送者与接受者的耦合才有可能出现“变化脆弱”的症状，职责链的目的就是将二者解耦，从而更好地应对变化。
在我们应用了Chain of Responsibility 模式后，对象的职责分派将更具灵活性。我们可以在运行时动态添加/修改请求的处理职责。
如果请求传递到职责链的末尾仍得不到处理，应该有一个合理的缺省机制。这也是每一个接受对象的责任，而不是发出请求的对象的责任。
《设计模式之禅》中定义使多个对象都有机会处理请求，从而避免了请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。
八、 Memento 备忘录
在软件构建过程中，某些对象的状态在转换过程中，可能由于某种需要，要求程序能够回溯到对象之前处于某个点时的状态。如果使用一些公有接口来让其他对象得到对象的状态，便会暴露对象的细节实现。
备忘录（Memento）存储原发器（Originator）对 象的内部状态，在需要时恢复原发器状态。
其中，Memento模式适用于“由原发器管理，却又必须存储在原发器之外的信息”在实现Memento模式中，要防止原发器以外的对象访问备忘录对象。备忘录对象有两个接口，一个为原发器使用的宽接口；一个为其他对象使用的窄接口。
在实现Memento模式时，要考虑拷贝对象状态的效率问题，如果对象开销比较大，可以采用某种 增量式改变来改进Memento模式。
《设计模式之禅》中定义Memento 备忘录，在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可以将该对象恢复到原先保存的状态。
九、State 状态
纵横谈里写道对象状态影响对象行为，不同的状态行使不同的行为。
其中，State模式将所有与一个特定状态相关的行为都放入一个State的子类对象中，在对象状态切换时，切换相应的对象；但同时维持State的接口，这样实现了具体操作与状态转换之间的解耦。
为不同的状态引入不同的对象使得状态转换变得更加明确，而且可以保证不会出现状态不一致的情况，因为转换是原子性的——即要么彻底转换过来，要么不转换。
如果State对象没有实例变量，那么各个上下文可以共享同一个State对象，从而节省对象开销。
允许一个对象在其内部状态改变时改变它的行为。从而使对象看起来似乎修改了其行为。
——《设计模式》
十、Strategy 策略模式
也叫做政策模式（Policy Pattern）
Strategy及其子类为组件提供了一系列可重用的算法，从而可以使得类型在运行时方便地根据需要在各个算法之间进行切换。所谓封装算法，支持算法的变化。
Strategy模式也提供了用条件判断语句以外的另一种选择，消除条件判断语句，就是在解耦合。含有许多条件判断语句的代码通常都需要Strategy模式。
与State类似，如果Strategy对象没有实例变量，那么各个上下文可以共享同一个Strategy对象，从而节省对象开销。
《设计模式之禅》中定义一系列算法，把它们一个个封装起来，并且使它们可互相替换。该模式使得算法可独立于使用它的客户而变化。使用的是面向对象的继承和多态机制。
十一、Visitor 访问者
表示一个作用于某对象结构中的各元素的操作。它可以在不改变各元素的类的前提下定义作用于这些元素的新的操作。
——《设计模式》
在软件构建过程中，由于需求的改变，某些类层次结构中常常需要增加新的行为（方法），如果直接在基类中做这样的更改，将会给子类带来很繁重的变更负担，甚至破坏原有设计。而Visitor模式通过所谓双重分发（double dispatch）来实现在不更改Element类层次结构的前提下，在运行时透明地为类层次结构上的各个类动态添加新的操作。
就是所谓双重分发即 Visitor模式中间包括了两个多态分发（注意其中的多态机制）：第一个为accept 方法的多态辨析；
第二个为visit方法的多态辨析。
最后Visitor模式的最大缺点在于扩展类层次结构（增添新的Element子类），会导致Visitor类的改变。因此Vistor模式适用于“Element类层次结构稳定，而其中的操作却经常面临频繁改动”。
