前言
继上次的指纹验证后，产品又提出了个项目典型需求：用户在未登录状态下，点击关注，跳转登录，登录成功后自动执行关注。
分析
这里有两个需求：
- 自动跳转到登录界面
- 登录成功后再自动执行关注行为
思考下抽象出通用性，首先，我们的目的是执行关注行为，但是关注行为需要用户处于登录状态。也就是说执行某个操作时需要满足一些前提条件，而这些前提条件是需要用户参与才能满足。可能存在多个前提条件的需求，这里可以分离出目标行为和前提条件行为。
技术选型
那就登录页面加个回调喽，登录成功就回调回去，不过，我们可不想在登录界面侵入太多逻辑代码，而且也违背了可维护性和通用性，难道以后扩展时，每个前置条件都要加回调？
再思考，第一想法是利用事件通知机制（EventBus、BroadcastReceiver），把登录成功这个事件 post 出去，异步执行关注行为。但如果前提条件有多个呢，是不是得发送多个事件？是不是得监听多个事件？而且，如果下次需求改了，目标事件不是执行关注事件了，而是执行发帖或者跳转到某个页面，那之前关注行为已经注册了，还是会通知到关注事件，难道要通过 msg 标志位来区分不同的目标行为吗？有没有更优雅简洁的方式呢？
再思考，如果用拦截器呢？
这种行为模式和拦截器非常相似，都是在执行目标前，判断是否符合条件。
但是拦截器似乎并不能直接完成我们的需求，因为我们需要插入一个验证行为后（例如进入登录界面），还要执行相应的操作，保证这个验证行为通过后，才能真正执行我们的目标行为。拦截器执行完后，马上会执行目标方法。中间并不会等待。所以我们根本没有办法去执行我们的登录操作，所以pass了。
那设计模式里的责任链模式，能不能提供点什么思路呢？
在责任链模式里，很多的处理对象由每一个对象对其下家的引用而联接起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。注意，是某一个！而我们的场景是，需要通过所有的前置条件验证，才能执行目标方法。
设计与实现
思考可以改良一下责任链，每一个前置条件对象（Valid类）不再持有其下家的引用，而是采用一个队列存储所有的前置条件对象，以先进先出的顺序依次验证条件。
private Queue<Valid> validQueue = new ArrayDeque<>();
前置条件对象抽象为接口Valid
public interface Valid {
/**
* 是否满足检验器的要求，如果不满足的话，则执行doValid()方法。如果满足，则执行目标action.call
* @return
*/
boolean preCheck();
/**
* 去执行验证前置行为，例如跳转到登录界面。（但并未完成验证。所以需要在登陆成功时调用preCheck()再次检查）
*/
void doValid();
}
可以看到，我们把前置条件对象的验证条件和操作分离开来。
目标对象Action就很简单了，仅拥有一个目标执行方法。
public interface Action {
void call();
}
整体的验证流程，如下图所示：
循环从前置条件对象队列 validQueue 里取出验证对象，调用 check 方法判断是否满足条件，不满足则进入该验证对象的验证流程，验证完毕，再次调用 check 方法判断满足条件，如果满足则取下一个，直至队列为空，就可以直接执行目标方法了。
那么前置条件对象队列 validQueue 和目标对象的持有方，我们封装为 Call，意为一次执行。
public class Call {
//目标对象
private Action action;
//先进先出验证模型
private Queue<Valid> validQueue = new ArrayDeque<>();
//上一个执行的valid
private Valid lastValid;
}
包装一个单例的持有Call对象的外观类 SingleCall，提供给业务层调用。
public class SingleCall {
private Call call = new Call();
public SingleCall addAction(Action action) {
clear();
call.setAction(action);
return this;
}
public SingleCall addValid(Valid valid) {
//只添加无效的，验证不通过的
if (valid.preCheck()) {
return this;
}
call.addValid(valid);
return this;
}
public void doCall() {
//如果上一条valid没有通过，是不允许再发起call的
if (call.getLastValid() != null && !call.getLastValid().preCheck()) {
return;
}
//如果全部都验证通过了，执行action
if (call.getValidQueue().size() == 0) {
if (call.getAction() != null) { //容错处理
call.getAction().call();
clear();
}
} else {
//执行验证
Valid valid = call.getValidQueue().poll();
call.setLastValid(valid);
valid.doValid();
}
}
.....
}
调用示例（常用场景，单 Action）：
Activity 实现 Action 接口，或 new 一个Action 实现类，实现 call 目标行为。
SingleCall.getInstance()
.addAction(ActionActivity.this)
.addValid(new LoginValid())//前置条件，可能有多个
.addValid(new OtherValid()
.doCall();
前置行为完成后，调用 SingleCall.getInstance().doCall(); 重新启动验证模型。因为验证操作需要用户手动触发完成，我们只是引导用户到了验证体里，由于我们因为等待用户的操作，验证模型就在这里停下来了，如果验证操作成功了，我们需要让整个验证模型再运转起来了，所以验证后，永远少不了手动开启验证模型。
以下是整个模型的类 UML 图，重点梳理 Valid、Call、Action 三者的关系：
应用场景
源码地址
- 增加了容错处理
- 补充了嵌套 Call 的情况
参考：
我是 FeelsChaotic，一个写得了代码 p 得了图，剪得了视频画得了画的程序媛，致力于追求代码优雅、架构设计和 T 型成长。
欢迎关注 FeelsChaotic 的简书和掘金，如果我的文章对你哪怕有一点点帮助，欢迎 ❤️！你的鼓励是我写作的最大动力！
最最重要的，请给出你的建议或意见，有错误请多多指正！
