Volley中的那些设计模式的身影~

文章摘要
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> 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));
            }
        }