再说职责链模式

     上篇文章里对本模式几乎没有说什么，只是推荐大家读了怪怪的一篇文章，这几天一直在思考本模式。现将自己的总

结写下来，欢迎大家指正。

      就像我上一篇文章里提到的一样，这个模式确实很难正确理解。MS很简单，但一写出来就不对。其实这个名字翻译的

不太好，如果翻译为 “响应链模式”我想更好理解一点。应用本模式应该注意以下几点。

1: 动态的响应请求,而且是多个都有可能处理该请求,没有一一对应关系 ,响应者是 不固定的.如果是一一对应的

   响应请求(固定响应请求关系)则使用表模式

2: 响应链做为一个整体来响应请求,由这个整体来决定谁是最佳响应者，而不是链上单一对象决定响应请求,其他

    传递请求.链上的对象都有可能处理请求是否响应是由对象自己的状态，而不是类别和传入信息或它们的对应关

    系决定。

3: 职责链中每一个对象都可能而且可以成为入口,而不是职责链头做为入口.无论从哪里进入, 都能找出这个入口对

    象最符合的响应对象.

4: 职责链可能用到组合模式,但和链表可能并没有太大关系,如果职责链模式 用链表来实现 很多时候 其实是误用.

5:“请求的响应者“如果 是多个的话 则有可能变成状态模式。

6：客户并不知道链上的哪一个对象最终处理这个请求，系统可以在不影响客户端的情况下动态地重新组织链和分

     配责任即链的组织形式与客户端没有关系.

7：误用了怎么办？如果误用了你的代码肯定会散发出臭味，重复的臭味或逻辑复杂的臭味。如果你能嗅出来，我

     想发挥你的才智应该也能解决问题。

8：其实我们追求的是优雅的设计而不是模式，你说是吗？那为什么我们在这儿费力的总结该模式呢？虽说，实际

    设计中我们一般都是慢慢地重构到模式，但如果你判断错误的话，可能重构的方向就会出现错误。等你发现时

    已经浪费了很多精力。