简述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));

}

}

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180815G0953N00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码关注腾讯云开发者

领取腾讯云代金券