深入浅出基于Java的责任链模式

一.导言

第一次看到责任链模型的时候，不禁想起以前听过的一句相声:见牙。讲的是一个病人在探视牙齿的时候，不小心把一颗牙齿掉进了病人的喉咙里。于是，病人楼上楼下跑了很多科室，最后一无所获。

责任链模型是“推卸”责任的模型。如果你的问题能和我一起解决，我就解决。如果没有，我就把你推到另一个对象。至于谁解决了这个问题？我不在乎！

二。定义和结构

你大概可以从名字中猜出这种模式的大致样子——系统中会有多个处理能力相似的对象。当请求被触发时，该请求将通过这些对象的链传递，直到找到并处理最合适的“责任”对象。

它在设计模式中的定义是:使多个对象有机会处理请求，从而避免请求的发送方和接收方之间的耦合关系。将这些对象连接成一个链，沿着链传递请求，直到有一个对象处理它。

从定义中可以看出，责任链模型的提出是为了“解耦”以应对系统需求的变化和模糊性。

以下是设计模式中给出的应用范围:

1)可以处理一个请求的对象有多个，自动确定哪个对象处理请求的运行时。

2)您希望向多个对象之一提交请求，而不明确指定接收者。

3)可以处理请求的对象集应该动态指定。

责任链模型真的能让发送者和接收者解耦吗(这似乎很神奇)？让我们先来看看它的组成角色。下面我会提到这个问题。

责任链模型由两个角色组成:

1)抽象处理程序:它定义了处理请求的接口。当然，对于链的不同实现，后继链也可以在这个角色中实现。

2)具体处理程序:实现抽象角色中定义的接口，处理它负责的请求。如果你处理不了，就去拜访它的继任者。

至于类图，就这样吧。毕竟是继承还是实现。

第三，纯与不纯

纯责任链模式和不纯责任链模式的区别就像黑猫和白猫的区别一样。不要刻意让你的代码符合一个模式的公式。只要代码能减少耦合，提高复用，满足系统需求，适应变化。俗话说:不管黑猫白猫，抓到老鼠就是好猫！

纯责任链模式规定一个特定的处理者角色只能对请求做出两个动作:自处理；传给下一个家庭。我们不能处理一部分，把剩下的传给下一个家庭。而且，请求必须在责任链中处理，不能有无果而终。

反之，则是不纯的责任链模式。

不纯的责任链模式还是责任链模式吗？例如，在一个请求被捕获后，每个特定的处理程序都会尝试处理它，并再次转发请求，而不管结果如何。我觉得这种模式的实现是不是一种责任链模式并不重要。重要的是，我们还可以从中体会到责任链模式的思想:通过在多个处理器之间建立链接，请求可以与特定的一个解耦。

下面的例子采用了上述的“不纯责任链模型”。