文章摘要
1、针对接口搭建的框架，才能更好的兼容变化。
2、volley中那些设计原则以及模式的身影。
附：获取Volley源代码
Demos案例源码：https://github.com/HailouWang/DemosForApi
从今天开始，会陆续介绍下Volley中那些实现机制以及设计模式，也欢迎大家将Volley的使用心得或者疑问发出来，大家一起Level Up ~
一、综述
针对 接口/超类型 编程，会让程序更好的兼容变化。这条设计原则，贯穿Volley工作流程实现的始终。我们可以数一下：
- 1、Request：新建一个请求，不同的请求，不同的数据解析方法。
- 2、Cache：缓存的处理，不同的处理，不同的子类来实现。
- 3、Network：解析网络数据。如果服务器有特定配置，可实现特定解析子类。
- 4、HttpStack：网络请求发送以及处理。不同的浏览器/不同的服务器，如果存在不同，提供了HurlStack、HttpClientStack不同的实现。
- 5、RetryPolicy：请求失败重试策略，可以针对具体的请求，实现自己的重试策略。
二、框架中的设计略影~
前面的几篇，有些来自官网的Demos，有些来自作者自己编写的案例，从整体上介绍了Volley的工作流程以及实现逻辑。同时，Volley作为一个短小但能力精悍的框架，还让我们可以从中汲取更多设计的营养，从设计模式的角度，包括但不限于：
- 1、设计原则：针对接口（超类型）编程，而不是针对实现编程。
- 在Volley中，网络请求封装成Request(Request是一个超类型)。
- 在Volley中，Request通过分发，首先需要从缓冲中去检索，不存在再去网络上同步。在此处所有的实现，针对的是Cache/Network接口，例如：NetworkDispatcher，组合引用了Cache/Network，而不是他们的实现类。
public class NetworkDispatcher extends Thread {
/** The queue of requests to service. */
private final BlockingQueue<Request<?>> mQueue;
/** The network interface for processing requests. */
private final Network mNetwork;
/** The cache to write to. */
private final Cache mCache;
- 2、设计原则：找出应用中可能需要变化的类，把他们独立出来，不要和那些不需要变化的代码混在一起。
如果代码中，每次需求已更新，都会使某方面的代码发生变化，那么我们即可以肯定，这部分代码应该被处理出来，和其他代码有所区分。
例如：Request为什么要那么多的实现类？
Request实现类
- 3、策略模式：定义了算法簇，分别封藏起来，让他们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。
HttpStack stack 是一个接口，定义了performRequest方法，用于真正和网络处理数据，不同的Android平台的设备，处理逻辑不同。组合接口的好处就是可以方便在不同的设备间切换。
if (stack == null) {
if (Build.VERSION.SDK_INT >= 9) {
stack = new HurlStack();
} else {
// Prior to Gingerbread, HttpUrlConnection was unreliable.
// See: http://android-developers.blogspot.com/2011/09/androids-http-clients.html
stack = new HttpClientStack(AndroidHttpClient.newInstance(userAgent));
}
}
