楼下一个男人并得要死，那家隔壁的一家唱着留声机，对面是弄孩子。楼上有两人狂笑；还有打牌声，河中的船上有女人哭她死去的母亲。人类的悲欢并不相通，我只觉得他们吵闹
——鲁迅
定义
使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理她为止
你玩过那种过关式的动作游戏吗？当你和小伙伴进入一个副本之后，必须按照副本的地图通过各个房间，最终干掉boss完成副本。这时候如果把玩家看作 请求，则副本就是一个职责链。所有的房间都有机会干掉玩家， 而玩家也有可能通过所有房间完成副本；而各个房间之间是不存在什么关联的，你可以把他们拆开另外组合
图纸
一个例子：如何把苹果放到合适的篮子里
无论是工厂、批发商还是其他的产品产出方，在自己的产品从成品到正式出货之前都要经过一系列的流程。哪怕是农民伯伯卖白菜，也会把烂叶子摘掉后再往外卖。现在如果我们要用代码来展示出货前的流程，我们该怎么做呢？
准备好了吗？这次的例子开始了
假定 生产苹果的大型基地A 需要根据采摘到的苹果的外观把苹果分成 X/Y/Z 三种类型的苹果（当然每种类型苹果价格不同） 。现在 A 为了推行全自动的出货模块，购入了一台 苹果外观打分器，这台机器可以根据输入的苹果的外观输出一个 外观分数，你的任务是根据这个 外观分数 和 你拿到的苹果，决定他应该被放到哪个篮子里，整个流程就像这样：
苹果分配器
为了完成这个任务，我们会创建一个 苹果分配器 让这个苹果分配器根据苹果的外观分数把他们放到不同的篮子里去，就像这样：
/**
苹果bean
**/
public class Apple {
/**
* 根据苹果外貌评分器写入的外貌分数
*/
private final float appearance;
public Apple(float appearance) {
this.appearance = appearance;
}
public float getAppearance() {
return appearance;
}
}
/**
* 苹果分配器
*/
public class AppleDispatcher {
/**
* 根据苹果的外貌分数把他们放入不同的篮子里
*/
public void dispatch(Apple apple) {
float appearance = apple.getAppearance();
if (appearance >= 75) {
//放入X类型的盒子中
} else if (appearance >= 45) {
//放入Y类型的盒子里
} else if (appearance > 0) {
//放入Z类型的盒子里
} else {
//外貌分<=0，证明出现了异常
throw new RuntimeException("输入的苹果的外貌分不合法，appearance=" + appearance);
}
}
}
我们创建了一个 AppleDispatcher 作为苹果分配器。其中有一个 dispatch 方法，接收一个苹果对象作为参数，然后根据里面的外貌分把他们分到不同的篮子里
不同的标准
上文的 AppleDispatcher 很好的完成了他的使命，但是系统运行一段时间后公司收到了一堆投诉，说是Z类型的盒子里出现了 被虫蛀的痕迹和摔烂的情况。经过QA部1同事夜以继日的加班，我们发现问题是出在外观分上：
我们的 苹果外观打分器 并不能识别出虫洞和掉到地上摔坏的痕迹，所以就算被检测的苹果被虫蛀了、烂了，也只是评分低一点，并不会不给他外貌分
于是我们决定修改现有的出货模块，新增以下规则：
- 当苹果的外观分<=45时，需要对其进行
外观检查，以判断是否被虫蛀 - 当苹果经过 外观检查 后发现没有被虫蛀，而是摔坏了，则输送到
牧场喂猪
也就是说，我们的流程要变成这样：
修改后的流程中新增了两个全新的分支，每一个苹果在进入 AppleDispatcher 的时候都有可能被分配到任何一个分支中，要怎么实现这样的效果呢？
组合对象
显而易见的一种方法，是直接在 AppleDispatcher 中添加逻辑，把所有的可能性都写出来。更进一步，你甚至可以定义一个验证器，用于抽象这个检查的过程，就像这样：
public class Apple {
/**
* 根据苹果外貌评分器写入的外貌分数
*/
private final float appearance;
/**
* 是否有虫
*/
private boolean haveWorm;
/**
* 是否摔伤
*/
private boolean isFall;
public Apple(float appearance) {
this.appearance = appearance;
}
public float getAppearance() {
return appearance;
}
public boolean isHaveWorm() {
return haveWorm;
}
public void setHaveWorm(boolean haveWorm) {
this.haveWorm = haveWorm;
}
public boolean isFall() {
return isFall;
}
public void setFall(boolean fall) {
isFall = fall;
}
}
public interface Verifier {
/**
* 验证
* @param apple 被验证的苹果
* @return true:通过验证
*/
boolean verify(Apple apple);
}
public class WormVerifier implements Verifier{
@Override
public boolean verify(Apple apple) {
return !apple.isHaveWorm();//返还这个苹果是否有虫
}
}
public class AppearanceVerifier implements Verifier{
@Override
public boolean verify(Apple apple) {
return !apple.isFall();//返还这个苹果是否摔伤
}
}
/**
* 苹果分配器
*/
public class AppleDispatcher {
/**
* 根据苹果的外貌分数把他们放入不同的篮子里
*/
public void dispatch(Apple apple) {
float appearance = apple.getAppearance();
if (appearance >= 75) {
//放入X类型的盒子中
} else if (appearance >= 45) {
//放入Y类型的盒子里
} else if (appearance > 0) {
if(new WormVerifier().verify(apple)){
//没有虫子
if(new AppearanceVerifier().verify(apple)){
//没有摔伤
//放入Z类型的盒子里
}else {
//喂猪
}
}else {
//直接报废
}
} else {
//外貌分<0，证明出现了异常
throw new RuntimeException("输入的苹果的外貌分不合法，appearance=" + appearance);
}
}
}
在这个实现里，我们通过建立 Verifier(验证器) 类簇把不同的验证方式封装到不同的类中，然后在 AppleDispatcher 中通过这些验证器的结果把苹果送到不同的结果分支中去，而且将来如果出现新的验证方式，我不需要修改已有的验证器，只需要新增子项。
但是这依然是很糟糕的设计
你可能发现了，我并没有组合 AppleDispatcher 和 Verifier，而是在 dispatch 方法中做紧耦合。这并不是我不想组合他们，而是我没办法组合他们，就算 Verifier 被解耦出来了，但是 AppleDispatcher 依然需要根据参数苹果在哪个验证器中被识别成异常，来决定苹果的走向
也就是说，AppleDispatcher 依然需要知道整个外观检查流程中的全部信息，只要我修改流程，还是要修改已经封装好的 dispatch 方法，这是我不愿意看到的
我希望有这样一个类的对象，可以在检测的同时直接对苹果做一个流向判断，而且不需要了解上下文此时的状态。而我在外部会给他提供一个调用环境，来调度当前的请求
当然有这样的写法，答案就是本文的主题，职责链
职责链
如果用职责链实现这个需求的话，是这样的：
AppleCheckExecutor
/**
* 苹果检查执行器
*/
public abstract class AppleCheckExecutor {
protected AppleHandler root;//根操作者
public AppleCheckExecutor() {
initHandleChain();
}
public void addAppleHandler(AppleHandler handler) {
if (root == null) {
root = handler;
} else {
addAppleHandler(handler, root);
}
}
private void addAppleHandler(AppleHandler handler, AppleHandler lastHandler) {
AppleHandler nextHandler = lastHandler.getNextHandler();
if (nextHandler == null) {
//没有下级Handler
lastHandler.setNextHandler(handler);
} else {
addAppleHandler(handler, nextHandler);
}
}
public void executor(Apple apple) {
if (root == null) {
//如果第一个处理器都没有写入，则直接执行默认处理方式
defaultHandle(apple);
} else {
Apple result = root.handle(apple);
if (result != null) {
//没有任何处理器相应
defaultHandle(apple);
}
}
}
/**
* 初始化处理器链
*/
protected abstract void initHandleChain();
/**
* 默认处理方式
*/
protected abstract void defaultHandle(Apple apple);
}
/**
* 高分执行器
*/
public class HeightExecutor extends AppleCheckExecutor{
@Override
protected void initHandleChain() {
//什么都不写入
}
@Override
protected void defaultHandle(Apple apple) {
//放入X类型的盒子中
}
}
/**
* 中等分数执行器
*/
public class MinExecutor extends AppleCheckExecutor{
@Override
protected void initHandleChain() {
//什么都不写入
}
@Override
protected void defaultHandle(Apple apple) {
//放入Y类型的盒子里
}
}
/**
* 低分执行器
*/
public class LowExecutor extends AppleCheckExecutor{
@Override
protected void initHandleChain() {
//写入外观检查流程
addAppleHandler(new WormHandler());
addAppleHandler(new AppearanceHandler());
}
@Override
protected void defaultHandle(Apple apple) {
//放入Z类型盒子中
}
}
AppleHandler
/**
* 苹果验证控制器
*/
public abstract class AppleHandler {
/**
* 下一级处理器
*/
protected AppleHandler nextHandler;
public AppleHandler() {
}
public AppleHandler getNextHandler() {
return nextHandler;
}
public void setNextHandler(AppleHandler nextHandler) {
this.nextHandler = nextHandler;
}
/**
* 验证是否通过这个控制器
*/
protected abstract boolean verify(Apple apple);
/**
* 未通过验证时需要执行的操作
*/
protected abstract void cannot(Apple apple);
/**
* 处理苹果
*/
public Apple handle(Apple apple) {
if (verify(apple)) {
//通过验证，把请求发送到下一级控制器中
if (nextHandler == null) {
//请求结束
return apple;
} else {
return nextHandler.handle(apple);
}
} else {
//没有通过验证
cannot(apple);
return null;
}
}
}
/**
* 虫子处理器
*/
public class WormHandler extends AppleHandler {
public WormHandler() {
}
@Override
protected void cannot(Apple apple) {
//报废
}
@Override
protected boolean verify(Apple apple) {
return !apple.isHaveWorm();//返还这个苹果是否有虫
}
}
/**
* 外观处理器
*/
public class AppearanceHandler extends AppleHandler {
public AppearanceHandler() {
}
@Override
protected boolean verify(Apple apple) {
return !apple.isFall();
}
@Override
protected void cannot(Apple apple) {
//喂猪
}
}
dispatcher
/**
* 苹果分配器
*/
public class AppleDispatcher {
private final AppleCheckExecutor heightExecutor = new HeightExecutor();//高分执行器
private final AppleCheckExecutor minExecutor = new MinExecutor();//中分执行器
private final AppleCheckExecutor lowExecutor = new LowExecutor();//低分执行器
/**
* 根据苹果的外貌分数把他们放入不同的篮子里
*/
public void dispatch(Apple apple) {
float appearance = apple.getAppearance();
if (appearance >= 75) {
heightExecutor.executor(apple);
} else if (appearance >= 45) {
minExecutor.executor(apple);
} else if (appearance > 0) {
lowExecutor.executor(apple);
} else {
//外貌分<0，证明出现了异常
throw new RuntimeException("输入的苹果的外貌分不合法，appearance=" + appearance);
}
}
}
在职责链的实现中，我们把对 苹果的安排的实现 委托给了 AppleCheckExecutor(苹果检查执行器)，AppleDispatcher 只对苹果的外观分数敏感，而不再关心苹果的命运。也就是说，除非以后公司修改对分数的划分，否则再也不需要修改 AppleDispatcher 里面的内容了
而在 AppleCheckExecutor 中，他又把具体的行为抛给了 AppleHandler(苹果处理器)，他把苹果当作一个请求，让 AppleHandler 之间自己建立连接，他只关心如果没有处理器处理苹果的情况
也就是说在 AppleCheckExecutor 里面，苹果是这样流通的：
这种写法是有意义的，事实上 AppleCheckExecutor 根本不关心一个苹果到底经历了多少检测，又或者是在哪一个检测里被刷掉的；他关心的只有这个苹果最终有没有通过检测
也就是说，先检查外观，还是先检查虫洞，对 AppleCheckExecutor 来说完全无所谓。甚至你往里面添加新的检查内容，他都无所谓，你只需要新增 AppleHandler 的子类，然后再修改对应的执行链里面的构成就可以了
但这也被认为是职责链的缺陷之一，调用者对执行链的内容太不关心，导致对请求到底在哪里被拦截一无所知
而这正是一个标准的职责链实现
碎碎念
职责链和事件响应
现在几乎所有的GUI框架都是通过 事件监听器 的模式
即 一个事件在某个组件上发生后，组件会发布一条信息出来，当有监听器在监听这个事件时就会被调用（这是一种观察者思想的实现，观察者会在后续文章中登场，敬请期待）
但问题是当 某个按钮和他身后的面板都有 单击事件监听器 的时候 ，我单击这个按钮，要怎么保证一定是最上方的按钮上的事件监听器被调用呢？
JavaScript中的事件响应处理就是这种思路，而他的解决方案就是职责链。把所有可以监听到当前事件的组件上注册的事件监听器组成一个职责链，然后把事件对象当作请求发送到这条职责链中。只要在职责链里被截获了， 那么后面的事件监听器就接收不到请求了（就像上例中的 WormHandler 截断请求后，AppearanceHandler 不会再进行处理一样）
职责链和组合
相信在上例的职责链实现中，你肯定对 AppleCheckExecutor 中的 root 产生了既视感
是的，这里就是用到了组合模式
事实上在实战中，职责链和组合基本都是成对出现的。因为职责链里面多个处理器需要被组合成前后项之间存在关联的一个整体，那这就可以被看成是一种树状结构
而树状结构用组合模式来实现是再合适不过的了
清晰的结构和复杂的代码
无论多牛的设计模式，都没逃过相同的宿命，即：
任何设计模式在让系统的结构更清晰的同时，也让代码变得更复杂
即使是结构最简单的单例模式或原型模式，也需要你书写比 A a = new A() 跟复杂的代码出来；但是我们在何时的情况下依然要使用他们，因为他们虽然让我们多写几行代码，但是他们对我们的系统友善，让我们把代码交给后辈时可以少挨两句骂
设计模式帮助你解耦，可是为了解耦，就一定要抽象一部分内容出来。在面向对象的环境下，抽象的最低粒度是接口
也就是说，原本可以写在一个函数里面的事情，现在你需要新建至少一个接口，并串联起他们。在这个过程中，代码的维护成本变高了，我们需要记住越来越多的类，理解越来越多对业务来说并没有什么卵用的——用于维护对象之间关系的代码
所以请让这些复杂的代码变得有意义，不要滥用设计模式
并不是什么时候都需要设计模式的，你可以为【Hello World】设计出什么模式呢？
但是如果就此认为我们研究设计模式毫无意义，又未免过于偏激。以前看过一本关于重构的书，书名已经记不起了，但是里面有段话印象深刻，大意如下：
你知道吗，其实大师级程序员和你之间的区别并不大。仅仅在于大师在开发系统的时候是在描述一个故事，他在描述这个系统应该具有什么样的行为；而你是在把脑海里的蓝图具体化成建筑。讲故事需要优雅的叙事手法，还有渊博的见闻作为佐料。而砌墙，需要的只是重复的搬砖
代码是艺术品，如果比喻成雕塑，设计模式就是你的板凿斧锯，没有这些东西，你做出来的作品注定称不上优雅
我只是希望你在某些应该用锉刀雕刻的细节上，不要用斧头去砍他
万分感谢您看完这篇文章，如果您喜欢这篇文章，欢迎点赞、收藏。还可以通过专栏，查看更多与【设计模式】有关的内容
QA，即 品质保证（Quality Assurance） ↩︎
