设计模式 - 状态模式、职责连模式
UML
| 状态模式 | 职责链模式 |
区别
我一直无法分析出两者真正的区别是什么，两者确实非常相似，他俩都代表着转移，甚至同一个问题都可以由两者分别完成。所以，我在网上搜了一个分析两者区别的文章，如下：
职责链模式：当客户提交一个请求时，请求是沿链传递直至有一个ConcreteHander对象负责处理它。接收者和发送者都没有对方的明确信息，且链中的对象自己并不知道链的结构，在运行时自动确定。结果是职责链可简化对象的相互连接，它们仅需保持一个指向其后继者的引用或指针，而不需要保持它所有的候选接受者。这也就大大降低了耦合度了。也就是说，我们可以随时地增加或修改处理一个请求的结构。增强了给对象指派职责的灵活性。
状态模式：状态模式主要解决的是当控制一个对象状态转换的条件表达式过于复杂的情况。把状态的判断逻辑转移到表示不同状态的一系列类当中，可以把复杂的判断逻辑简化。状态模式将与特定状态相关的行为局部化，并且将不同状态的行为分割开来。即将特定的状态相关的行为都放入一个对象中，由于所有与状态相关的代码都存在于某个ConcreteState中，所以通过定义新的子类可以很容易地增加新的状态和转换。这样做的目的是为了消除庞大的条件分支语句。状态模式通过把各种状态转移逻辑分布到State的子类之间，来减少相互间的依赖。
个人认为，职责链模式与状态模式的最大的不同是设置自己的下一级的问题上，状态模式是在类的设计阶段就定好的，不能在客户端改变，而职责链的下一级是在客户端自己来确定的。这样各有什么优缺点呢？
在类的设计阶段设定（状态模式）的好处是不用客户来确定下一状态，也就减少了客户设置错误的问题，客户也不用知道状态的具体结构，同时存在灵活性差，耦合度高的问题，从上面的例子可以看到，因为作用域的问题，ConStateC一定要写在ConStateB之前，ConStateB一定要写在ConStateA之前，顺序不能乱。而在客户端设定（职责链模式）要求客户对各个类的职责要有所了解，并能正确设置好职责链，并加大设置出错的风险。但是它也比较灵活，也不存在刚才在状态模式中说的耦合和作用域问题。
状态模式：状态模式主要解决的是当控制一个对象状态转换的条件表达式过于复杂的情况。把状态的判断逻辑转移到表示不同状态的一系列类当中，可以把复杂的判断逻辑简化。状态模式将与特定状态相关的行为局部化，并且将不同状态的行为分割开来。即将特定的状态相关的行为都放入一个对象中，由于所有与状态相关的代码都存在于某个ConcreteState中，所以通过定义新的子类可以很容易地增加新的状态和转换。这样做的目的是为了消除庞大的条件分支语句。状态模式通过把各种状态转移逻辑分布到State的子类之间，来减少相互间的依赖。
个人认为，职责链模式与状态模式的最大的不同是设置自己的下一级的问题上，状态模式是在类的设计阶段就定好的，不能在客户端改变，而职责链的下一级是在客户端自己来确定的。这样各有什么优缺点呢？
在类的设计阶段设定（状态模式）的好处是不用客户来确定下一状态，也就减少了客户设置错误的问题，客户也不用知道状态的具体结构，同时存在灵活性差，耦合度高的问题，从上面的例子可以看到，因为作用域的问题，ConStateC一定要写在ConStateB之前，ConStateB一定要写在ConStateA之前，顺序不能乱。而在客户端设定（职责链模式）要求客户对各个类的职责要有所了解，并能正确设置好职责链，并加大设置出错的风险。但是它也比较灵活，也不存在刚才在状态模式中说的耦合和作用域问题。
