责任链模式、状态模式

责任链（Chain of Responsibility）模式

定义：为了避免请求发送者与多个请求处理者耦合在一起，将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链；当有请求发生时，可将请求沿着这条传递链，知道有对象处理它为止。

优缺点

优点：

1. 降低了对象之间的耦合度。该模式使得一个对象无需知道是哪一个对象处理其请求以及链的结构，发送者和接收者也无需拥有对方明确的消息。
2. 增强了系统的可扩展性。可以根据需要增加新的请求处理类，满足开闭原则；
3. 增强了给对象指派职责的灵活性。当工作流程发生变化，可以动态地改变链内的成员或者调动他们的次序，也可以动态地新增或者删除责任。
4. 职责链简化了对象之间的连接。每个对象只需要保持一个指向其后继者的引用，不需保持其它所有处理者的引用，这避免了使用众多的if或者if-else语句
5. 责任分担。每个类只需要吃力自己该处理的工作，不该处理的传递给下一个对象完成，明确各类的责任方位，符合类的单一职责原则。

缺点：

1. 不能保证每个请求一定被处理。由于一个请求没有明确的接收者，所以不能保证它一定被处理，该请求可能一直传到链的末端都得不到处理。
2. 对于比较长的职责链，请求的处理可能设计到多个处理对象，系统性能将受到一定的影响。
3. 职责链建立的合理性要客户端来保证，增加了客户端的复杂性，可能会由于职责链的错误设置而导致系统出错，如：可能会造成循环调用。

应用场景

1. 有多个对象可以处理一个请求，哪个对象处理该请求由运行时刻自动确定。
2. 可以动态指定一组对象处理请求，或添加新的处理者。
3. 在不明确指定请求处理者的情况下，向多个处理者种的一个提交请求。

主要角色

1. 抽象处理者（Handler）角色：定义一个处理请求的接口，包含抽象处理方法和一个后继连接。
2. 具体处理者（ConcreteHandler）角色：实现抽象处理者的处理方法，判断能否处理本次请求，如果可以处理请求则处理，否则将该请求转给他的后继者。
3. 客户类（Client）角色：创建处理链，并向链头的具体处理者对象提交请求，它不关心处理细节和请求的传递过程。

结构图

应用实例

用职责链设计一条请假条审批模块
假如规定学生请假小于或等于2天，班主任可以批准；小于或等于7天，系主任可以批准；小于等于10天，院长可以批准；其余情况不予批假。结构图如下：

职责链模式的扩展

1. 纯的职责链模式：一个请求必须被某一个处理对象所接受，且一个具体处理者对某个请求的处理只能采用以下两种行为之一：
   a. 自己处理（承担责任）
   b.把责任推给下家处理
   2.不纯的职责链模式：允许出现某一个具体处理对象在承担了请求的一部分责任后又将剩余的责任传给下家的情况，且一个请求可以最终不被任何接收端对象所接收。

状态（State）模式

定义：对于有状态的对象，把复杂的“判断逻辑”提取到不同的状态对象中，允许状态对象在其内部状态发生改变时改变其行为。

优缺点

优点：

1. 状态模式将与特定状态相关的行为局部化到一个状态中，并且将不同状态的行为分割开来，满足“单一职责原则”；
2. 减少对象间的相互依赖。将不同的状态引入到独立的对象中会使得状态转换更加明确，且减少对象间的相互依赖；
3. 有利于程序的扩展。通过定义新的子类很容易地增加新的状态和转换。

缺点：

1. 状态模式的使用必然会增加系统的类和对象的个数；
2. 状态模式的结构与实现都比较复杂，如果使用不当会导致程序结构和代码的混乱。

应用场景

1. 当一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为时，就可以考虑使用状态模式。
2. 一个操作中含有庞大的分支结构，并且这些分支决定于对象的状态时。

主要角色

1. 环境（Context）角色：也称为上下文，它定义了客户感兴趣的接口，维护一个当前状态，并将与状态相关的操作委托给当前状态对象来处理。
2. 抽象状态（State）类：定义一个接口，用以封装环境对象中的特定状态所对应的行为。
3. 具体状态（ConcreteState）角色：实现抽象状态所对应的行为。

结构图

应用实例

本案例包括“不及格”、“中等”和“优秀”3种状态。当学生的分数小于60分时为“不及格”状态，当分数大于等于60分且小于90分为“中等”状态；当分数大于等于90分时为“优秀”状态。结构图如下：

注意：该文章内容采摘于《软件设计模式（Java版）》，作者：程细柱