写到现在，不知道大家是否发现一个问题？我们所有的请求逻辑实际上，都是在Realcall的封装线程里面执行的，但是我们还没有处理不同的状态码返回、缓存利用、重试连接等等逻辑，如果后续我们都把这些功能封装为一个一个的函数，写在Realcall里面，显而易见，对于一个框架设计实现本身，就是灾难，更别谈后续的使用、维护、功能迭代了。
1. 设计的思考过程
最简单的，小编现在就能想到的问题有：
- Realcall明显功能越来越多，这在设计上是不被允许的
- 不同的请求，可以使用不同的缓存策略，就好像我们之前自己实现的Imageloader一样，缓存框架和下载框架是可以通过外部自定义去实现替换的，来替换okhttp、volley各种的依赖
大家还记得我们之前《Android源码设计模式探索与实战》课程中，讲到过责任链模式吗？
应用到程序设计中，我们把责任链模式这样定义：用于进行请求者和处理者之间的解耦的一种设计模式，把同一个请求，链式按顺序传递给链上的每个处理者，如果当前处理者处理，则完成，如果当前处理者不处理，则继续向下传递。
这里请求-响应，功能的划分顺序执行上，可以使用责任链设计模式，可以让其顺序执行，拦截器的设定，必定是一个接口。拦截器拥有的功能的话，从责任链模式的定义，我们也能了解到，责任链模式的每个拦截器，