简述Volley中的那些设计模式的身影

文章摘要

1、针对接口编程，才能更好的兼容变化。

2、volley中那些设计原则以及模式的身影。

附：获取Volley源代码：https://github.com/google/volleyDemos案例源码：https://github.com/HailouWang/DemosForApi一、综述

针对 接口/超类型 编程，会让程序更好的兼容变化。这条设计原则，贯穿Volley工作流程实现的始终。在Volley的实现元素中：请求、缓冲设计、网络设计、请求重试策略等都可以看到设计模式以及设计原则的身影：

1、Request：不同的请求对应不同的解析逻辑，进而得到对应的Response。

2、Cache：缓存的处理，不同的缓存策略，由不同的子类来实现。

3、Network：解析网络数据，构建Response。不同的服务器返回的请求结果方式不同，可由不同的HttpStack来处理这些方式。例如：Mock服务器处理模拟数据，进而转化为Response，Volley中，提供了HurlStack、HttpClientStack、MockHttpStack等不同的实现。

4、RetryPolicy：请求失败重试策略，请求不同，重试机制的实现也不同。

二、设计模式身影

来自官网的Demos，从整体上介绍了Volley的工作流程以及实现逻辑。Volley作为一个短小但能力精悍的框架，在我们的平时工作中，无论是架构设计还是代码实现，都可以提供很多思路。关于其用到的设计原则，包括但不限于：

1、设计原则：针对接口（超类型）编程，而不是针对实现编程。

Request请求：在Volley中，网络请求封装成Request(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、设计原则：找出应用中可能需要变化的类，把他们独立出来，不要和那些不需要变化的代码混在一起。

实现逻辑中，需求的变更/迭代，某方面的“逻辑/策略”会随着更新/修改，那么，这部分代码应该被独立出来，和其他无需改动的代码分开。

例如：在Volley实现中，Request有众多的实现类，这是因为每个Request包含的请求参数都不同，为了让它们互不影响、互不干扰，定义“策略”类将它们分开。

3、策略模式：定义了算法簇，分别封藏起来，让他们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。

HttpStack 定义了处理网络请求(performRequest)方法，用于真正和网络处理数据。Volley作为一个框架，可以运行不同的Android SDK API 设备上，不同SDKHttpStack 可以使用的特性也不同，故而：在Volley框架中，定义超类型(HttpStack) 算法簇，根据SDK API版本，让它们之间相互替换 。

if(stack ==null) {

if (Build.VERSION.SDK_INT >= 9) {

stack = new HurlStack();

} else {

stack = new HttpClientStack(

AndroidHttpClient.newInstance(

userAgent));

}

}