责任链模式以及在 Android 中的应用

public Handler getNextSucccesor() {

return mNextHandler;

}

@Override

public void handleRequest(int dayNums) {

if (dayNums <= mCouldHandlerNum) {

System.out.println(mName + " 同意了你的申请， dayNums = " + dayNums);

} else {

Handler nextSucccesor = getNextSucccesor();

if (nextSucccesor != null) {

nextSucccesor.handleRequest(dayNums);

} else {

System.out.println(mName + " 拒绝了你的申请 dayNums = " + dayNums);

}

}

}

}

leader 类，实现了 Handler 接口，主要看 handlerRequest 方法，他封装了一些基本的逻辑

1. 当请求天数少于 mCouldHandlerNum 即能够处理的最大天数，直接交给当前处理者处理

2. 否则，交给下一个处理者处理。

Leader 的子类

public class TeamLeader extends Leader {

public TeamLeader(String name, int couldHandlerNum) {

super(name, couldHandlerNum);

}

}

public class Departmentdirector extends Leader{

public Departmentdirector(String name, int couldHandlerNum) {

super(name, couldHandlerNum);

}

}

public class GeneralManager extends Leader{

public GeneralManager(String name, int couldHandlerNum) {

super(name, couldHandlerNum);

}

}

可以看到， 这里我们 leader 的子类只重写了构造方法，并没有重写其他方法。这是因为 handleRequest 的基本逻辑我们已经基类当中，子类不需要重写。因此，这里的 DirectLeader,Departmentdirector,GeneralManager 实际上是可有可无的。

然而，在实际开发当中，部分总经理，总经理，他们的职责肯定有很多不同，所以这里分别用不同的子类实现。

测试代码

package com.xj.chain;

public class ClientTest {

public static void main(String[] args) {

Leader directLeader = new TeamLeader(“TeamLeader”, 3);

Leader departmentdirector = new Departmentdirector(“Departmentdirector”, 7);

Leader generalManager = new GeneralManager(“GeneralManager”, Integer.MAX_VALUE);

directLeader.setSuccesor(departmentdirector);

departmentdirector.setSuccesor(generalManager);

// 请假三天

directLeader.handleRequest(3);

// 请假六天

directLeader.handleRequest(6);

// 请假100天

directLeader.handleRequest(100);

}

}

运行以上代码，可以看到以下输出

DirectLeader 同意了你的申请， dayNums = 3

Departmentdirector 同意了你的申请， dayNums = 6

GeneralManager 同意了你的申请， dayNums = 100

---

优缺点分析

---

从上面请假的例子中，我们可以看到，当我们需要请假的时候，我们直接调用请假的接口，无需关心处理者到底是谁，即把请求者和处理者之间的逻辑剥离开来，降低耦合度。同时，如果我们需要增加新的处理者的话，我们只需要重新组合链表即可。

有优点也必定有缺点，比如，当链表很长的时候，一级一级请求，在性能上可能会有一些影响。同时，如果我们没有正确设置处理者，可能会导致请求没有人处理。

因此，优缺点总结如下。

优点：

1. 请求者与处理者降低耦合度，他们之间甚至可以互相不知道对方的存在

2. 增加新的处理类很方便

优点：

1. 对性能可能会有一定的影响，当链表很长的时候，一级一级调用，处理的时间可能会比较长

---

责任链模式在 Android 中的体现

---

ViewGroup 事件传递

还记得 Android 总的事件分发机制吗，主要有三个方法，dispatchTouchEvent,onInterceptTouchEvent,onTouchEvent 三个方法

• dispatchTouchEvent ，这个方法主要是用来分发事件的

• onInterceptTouchEvent，这个方法主要是用来拦截事件的（需要注意的是ViewGroup才有这个方法，View没有onInterceptTouchEvent这个方法

• onTouchEvent这个方法主要是用来处理事件的

• requestDisallowInterceptTouchEvent(true)，这个方法能够影响父View是否拦截事件，true表示 不拦截事件，false表示拦截事件

下面引用图解 Android 事件分发机制这一篇博客的内容

当TouchEvent发生时，首先Activity将TouchEvent传递给最顶层的View，TouchEvent最先到达最顶层 view 的 dispatchTouchEvent ，然后由 dispatchTouchEvent 方法进行分发，

1. 如果dispatchTouchEvent返回true 消费事件，事件终结。

2. 如果dispatchTouchEvent返回 false ，则回传给父View的onTouchEvent事件处理；

• onTouchEvent事件返回true，事件终结，返回false，交给父View的OnTouchEvent方法处理

3. 如果dispatchTouchEvent返回super的话，默认会调用自己的onInterceptTouchEvent方法

• 默认的情况下interceptTouchEvent回调用super方法，super方法默认返回false，所以会交给子View的onDispatchTouchEvent方法处理

• 如果 interceptTouchEvent 返回 true ，也就是拦截掉了，则交给它的 onTouchEvent 来处理，

• 如果 interceptTouchEvent 返回 false ，那么就传递给子 view ，由子 view 的 dispatchTouchEvent 再来开始这个事件的分发。

通过这样链式的设计，确保了每一个 View 都有机会处理 touch 事件。如果中途有 View 处理了事件，就停止处理。

有序广播

Android 中的 BroastCast 分为两种，一种时普通广播，另一种是有序广播。普通广播是异步的，发出时可以被所有的接收者收到。而有序广播是根据优先级一次传播的，直到有接收者将其终止或者所有接收者都不终止它。有序广播的这一特性与我们的责任链模式很相近，我们可以轻松地实现一种全局的责任链事件处理。

---

题外话

---

关于责任链模式，你还想到了什么？欢迎留言探讨。

观察者设计模式 Vs 事件委托（java）

装饰者模式及其应用

建造者模式（Builder）及其应用

二次封装图片第三方框架——简单工厂模式的运用

Android 二次封装网络加载框架

java 代理模式详解

最后

在这里小编整理了一份Android大厂常见面试题，和一些Android架构视频解析，都已整理成文档，全部都已打包好了，希望能够对大家有所帮助，在面试中能顺利通过。

喜欢本文的话，不妨顺手给我点个小赞、评论区留言或者转发支持一下呗

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！
id 二次封装网络加载框架]( )

java 代理模式详解

最后

在这里小编整理了一份Android大厂常见面试题，和一些Android架构视频解析，都已整理成文档，全部都已打包好了，希望能够对大家有所帮助，在面试中能顺利通过。

[外链图片转存中…(img-MIac9f43-1715396919055)]

[外链图片转存中…(img-8pA6sXoJ-1715396919056)]

喜欢本文的话，不妨顺手给我点个小赞、评论区留言或者转发支持一下呗

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！