仍记得前年的这个时候我去一个新的公司报道，公司总共就十来个人做开发，刚好做 android 的那哥们离职，就丢了一个项目给我。后面的日子我算是饱受煎熬，今天我们以一个访问网络的部分，来给大家做一下讲解。里面每次获取接口数据是这样的： 当时我看到这个的时候觉得没什么，只是我想换一下网络请求的框架，想把它换成 OKHttp ，我一直不喜欢用 xUtils。但后来想想还是算了，好几十个地方那我不都得去改？得过且过吧。过了一段时间后台突然说，我们需要加个平台参数来区别到底是 android 端还是 iOS 端，每个接口都多带个参数 platform = android。听到这个的我眼泪掉下来，默默无闻的回家找了好几个小时，所有访问接口都统一加了个参数。第二天早上我其实就想到，我为什么不去改 xUtils 的源代码呢？看来昨天那几个小时白忙活了。这个时候我其实还没有意识到我要去更换整个网络架构，尽管我知道后面还是会有问题，得过且过吧。刚过几天测试发现有些页面有时候会崩掉有时候又不会，我一看后台接口返回的数据接口尼玛… 有数据的情况下： 无数据的情况下： 我记得我当时想去找后台，让他帮帮忙，但是问问 iOS 的那哥们他说他做了一些处理。我心里在想我不能就这么暴露我自己，因此下定决心要自己来封装。所以就出现了我接下来要写的这篇文章，我记得我在内涵段子项目部分写过这个内容，但是那时是授人以鱼，这次是要授人以渔。说明我不是乱写还是有很扎实的理论依据，这是理论结合实战的年代，当然我也不会写得太完善很多问题会留作思考，授人以鱼不如授人以渔。
上面这种写法应该只有学校的老师才会教我们这样写吧，我以 OKHttp 为例，这种我就不写了，写一个稍微好一点的级别，请看初步版本：
调用部分
Map<String, Object> params = new HashMap<>(); // 特定参数 params.put("iid", 6152551759L); params.put("aid", 7); HttpUtils.get(this, ConstantValue.UrlConstant.HOME_DISCOVERY_URL, params, true, new HttpCallBack<DiscoverListResult>() { @Override public void onSuccess(DiscoverListResult result) { if (result.isOK()) { // 没有列表数据的情况, 打印 Toast 或者做一些其他处理 } else { // 有数据列表的情况，显示列表 showListData(result); } } @Override public void onFailure(Exception e) { } });封装部分
/** * get 请求数据列表 * @param context 上下文 * @param url 访问路径 * @param params 访问参数 * @param cache 是否缓存 * @param callback 数据解析回调 * @param <T> 解析类的泛型 */ public static <T> void get(Context context, String url, Map<String, Object> params, final boolean cache, final HttpCallBack<T> callback) { OkHttpClient mOkHttpClient = new OkHttpClient(); // 公共参数拼接 params.put("app_name", "joke_essay"); params.put("version_name", "5.7.0"); params.put("ac", "wifi"); params.put("device_id", "30036118478"); params.put("device_brand", "Xiaomi"); params.put("update_version_code", "5701"); params.put("manifest_version_code", "570"); params.put("longitude", "113.000366"); params.put("latitude", "28.171377"); params.put("device_platform", "android"); final String jointUrl = Utils.jointParams(url, params); //打印 // 缓存逻辑的一些处理 Request.Builder requestBuilder = new Request.Builder().url(jointUrl).tag(context); //可以省略，默认是GET请求 Request request = requestBuilder.build(); // 异步请求数据 mOkHttpClient.newCall(request).enqueue(new Callback() { @Override public void onFailure(Call call, final IOException e) { // 失败 callback.onFailure(e); } @Override public void onResponse(Call call, Response response) throws IOException { final String resultJson = response.body().string(); // json 转换，有无数据列表，缓存处理 } }); }这个看上去就稍微好一丁点了，至少也能解决掉一些问题，当然有些哥们估计是用的别人封装好的那就另当别论了，其实前年网上对 OKHttp 的封装还是比较少，关键不是不想而是很少。
随着项目越来越大功能越来越强，这明显满足不了功能，而且人员也越来越多的情况下，吐槽随之而来，比如不支持 cookie ， https 证书，超时断线重连等等。好吧硬着头皮去加了一下功能，这个时候问题就来了，就是一个方法要传的参数一大堆，后面要跟十几个参数，而有些参数我又不想要，只能全都传 null 。第一，成员调用非常蛋疼需要对照你的参数一个一个去看，第二，可阅读并不好并不美观，所以又做了如下修改，最终调用就变成了如下方式：
HttpUtils.with(this) .get() // get请求 .param("aid", 7)// 添加单个参数，params 可以添加多个参数 .param("iid", 6152551759L) .url(ConstantValue.UrlConstant.HOME_DISCOVERY_URL)// 接口地址 .setCookie(true)//配置是否使用cookie .cache(true)//设置是否使用缓存，如果使用缓存必须设置为true .retryDelayMillis(1000)//配置请求失败重试间隔时间，单位毫秒 .retryCount(3)//配置请求失败重试次数 .execute(new HttpCallBack<DiscoverListResult>() { @Override public void onSuccess(DiscoverListResult result) { if (result.isOK()) { // 没有列表数据的情况, 打印 Toast 或者做一些其他处理 } else { // 有数据列表的情况，显示列表 showListData(result); } } @Override public void onFailure(Exception e) { } });这时技术总监就上来问了，目前所有的功能都写在一个类里怎么行呢，这样随着功能的增多，HttpUtils 类会越来越大，代码也越来越复杂。这样一看我的 HttpUtils 简直就没有设计可言，更不要说扩展性、灵活性了。网络加载封装就越来越脆弱…… 回家想了半天，那我多拆几个类出来不就行了？到底怎么拆这个时候 单一职责就来了。
单一职责原则的英文名称是Single Responsibility Principle，简称SRP。它的定义是：就一个类而言，应该仅有一个引起它变化的原因。简单来说，一个类中应该是一组相关性很高的函数、数据的封装。这个在 《Android 源码设计模式》那本书中讲得很清楚，学了就要用，到底是什么意思？请看我如何拆分，贴一些事例代码。
/** * Email 240336124@qq.com * Created by Darren on 2017/3/12. * Version 1.0 * Description: */ public class HttpCache { /** * 获取数据 */ public String getCache(String finalUrl) { // 省略一些代码 ... } /** * 缓存数据 */ public long saveCache(String finalUrl, String resultJson) { // 省略一些代码 ... } } public class HttpUtils { private OKHttpRequest mHttpRequest; private HttpUtils(Context context) { mHttpRequest = new OKHttpRequest(); mHttpRequest.with(context); } // 省略一些代码 ... }代码提交之后感觉思路是对的，后来一想最根本的问题还是没有解决，我当初的第一感觉是想把 xutils 换成 OkHttp，但是我没想过要去改每个接口，比如后来接着 Retrofit 又出来了，以后还指不定要出一些什么，我想能不能再写得强大一些，可以切换，而不用改动原来的代码。到底应该怎么办？开闭原则就来了。
开闭原则的英文全称是Open Close Principle，简称OCP，它是Java世界里最基础的设计原则，它指导我们如何建立一个稳定的、灵活的系统。开闭原则的定义是：软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是，对于修改是封闭的。我的理解是对于原来写好的代码里面是不可修改，但是对于外部又是可扩展的。理解起来还是有点抽象，结合一下我的代码就会好些，又要改了其实就是多了一个接口而已。
/** * description: * author: Darren on 2017/8/21 11:36 * email: 240336124@qq.com * version: 1.0 */ public class HttpUtils { // 这个可以在 application 中去初始化 private static IHttpRequest mInitHttpRequest; private IHttpRequest mHttpRequest; public static void initHttpRequest(IHttpRequest httpRequest) { mInitHttpRequest = httpRequest; } // 如果有两种的情况下 比如 volley 下载文件并不是很屌 ，那么可以换成 OKHttp public HttpUtils httpRequest(IHttpRequest httpRequest) { this.mHttpRequest = httpRequest; return this; } // 省略部分代码 ...... public <T> void execute(HttpCallBack<T> callback) { // 如果没有指定，那么就用 application 中初始化的 if(mHttpRequest == null){ mHttpRequest = mInitHttpRequest; } mHttpRequest.get(mContext, mParams, mUrl, mCache, callback); } }IHttpRequest 代码
/** * description: * author: Darren on 2017/8/24 11:34 * email: 240336124@qq.com * version: 1.0 */ public interface IHttpRequest { /** * post 提交 * * @param context * @param params * @param url * @param cache * @param callback * @param <T> */ <T> void post(Context context, Map<String, Object> params, String url, final boolean cache, final HttpCallBack<T> callback); /** * get 提交 * * @param context * @param params * @param url * @param cache * @param callback * @param <T> */ <T> void get(Context context, Map<String, Object> params, String url, final boolean cache, final HttpCallBack<T> callback); }OKHttpRequest 代码
/** * description: * author: Darren on 2017/8/24 10:32 * email: 240336124@qq.com * version: 1.0 */ public class OKHttpRequest implements IHttpRequest { private HttpCache mHttpCache; private OkHttpClient mOkHttpClient; public OKHttpRequest() { mHttpCache = new HttpCache(); mOkHttpClient = new OkHttpClient(); } @Override public <T> void post(Context context, Map<String, Object> params, String url, boolean cache, HttpCallBack<T> callback) { // 省略部分代码 ...... } public <T> void get(Context context, Map<String, Object> params, String url, final boolean cache, final HttpCallBack<T> callback) { // 省略部分代码 ...... } }XUtilsRequest 代码
/** * description: * author: Darren on 2017/8/24 10:32 * email: 240336124@qq.com * version: 1.0 */ public class XUtilsRequest implements IHttpRequest { private HttpCache mHttpCache; public XUtilsRequest() { mHttpCache = new HttpCache(); } @Override public <T> void post(Context context, Map<String, Object> params, String url, boolean cache, HttpCallBack<T> callback) { // 省略部分代码 ...... } public <T> void get(Context context, Map<String, Object> params, String url, final boolean cache, final HttpCallBack<T> callback) { // 省略部分代码 ...... } }Application 代码
/** * description: * author: Darren on 2017/8/21 15:05 * email: 240336124@qq.com * version: 1.0 */ public class BaseApplication extends Application { @Override public void onCreate() { super.onCreate(); PreferencesUtil.getInstance().init(this); x.Ext.init(this); // 初始化指定网络请求 HttpUtils.initHttpRequest(new XUtilsRequest()); } }开闭原则指导我们，当软件需要变化时，应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。我们尽量不要通过继承等方式添加新的实现，这会导致类型的膨胀以及历史遗留代码的冗余。我们的开发过程中也没有那么理想化的状况，完全地不用修改原来的代码，因此，在开发过程中需要自己结合具体情况进行考量，是通过修改旧代码还是通过继承使得软件系统更稳定、更灵活，在保证去除“代码腐化”的同时，也保证原有模块的正确性。当然如果等我们了解了 Builder 设计模式或者加入其他的一些设计模式之后我们肯定可以写得更强大和完善。我们接着往下面看。
里氏替换原则英文全称是Liskov Substitution Principle，简称LSP。我们知道，面向对象的语言的三大特点是继承、封装、多态，里氏替换原则就是依赖于继承、多态这两大特性。里氏替换原则简单来说就是，所有引用基类的地方必须能透明地使用其子类的对象。通俗点讲，只要父类能出现的地方子类就可以出现。但是，反过来就不行了，有子类出现的地方，父类未必就能适应。 我们简单的看几个使用场景，在我们的开发过程中无所不在。
// 1. 今天所写的初始化请求 HttpUtils.initHttpRequest(new XUtilsRequest()); HttpUtils.initHttpRequest(new OKHttpRequest()); // 2. RecyclerView 的 LayoutMananger mRecyclerView.setLayoutManager(new LinearLayoutManager(this)); mRecyclerView.setLayoutManager(new GridLayoutManager(this,3)); // 3. Retrofit 添加解析工厂 等等使用的地方非常之多，setLayoutManager 的源码大家可以自己去了解一下，上面的代码就很好的反应了里氏替换原则，XUtilsRequest、OKHttpRequest 都可以替换 IHttpRequest 的工作。IHttpRequest 建立了 post 请求，get 请求，上传，下载的接口规范，XUtilsRequest 等根据接口规范实现了相应的功能，用户只需要在 Application 中指定具体的缓存对象就可以动态地替换 IHttpRequest 中的请求。这就使得网络请求具有了无线的可能性，也就是保证了可扩展性。
里氏替换原则和开闭原则有点相似，但仔细理解他们之间是不同的概念，只能够说是有时候开闭原则和里氏替换原则往往生死相依、不弃不离，通过里氏替换来达到对扩展开放，对修改关闭的效果，这两个原则其实就是面向对象思想中的抽象。
依赖倒置原则英文全称是Dependence Inversion Principle，简称DIP。依赖反转原则指代了一种特定的解耦形式，高层模块不依赖低层次模块的细节，说白了高层次就是不依赖细节而是依赖抽象。那什么又是低层次什么是高层次？拿上面开闭原则那张图来讲，HttpUtils 是高层次，IHttpRequest、XUtilsRequest 和 OKHttpRequest 是低层次。刚开始 HttpUtils 是这么写的：
public class HttpUtils { private OKHttpRequest mHttpRequest; private HttpUtils(Context context) { mHttpRequest = new OKHttpRequest(); mHttpRequest.with(context); } // 省略一些代码 ... }这个时候我们依赖的是具体的 OKHttpRequest，这种情况下很明显我们依赖的是具体的细节， 在开闭原则过后，我们 HttpUtils 是这么写的。
/** * description: * author: Darren on 2017/8/21 11:36 * email: 240336124@qq.com * version: 1.0 */ public class HttpUtils { // 这个可以在 application 中去初始化 private static IHttpRequest mInitHttpRequest; private IHttpRequest mHttpRequest; public static void initHttpRequest(IHttpRequest httpRequest) { mInitHttpRequest = httpRequest; } // 如果有两种的情况下 比如 volley 下载文件并不是很屌 ，那么可以换成 OKHttp public HttpUtils httpRequest(IHttpRequest httpRequest) { this.mHttpRequest = httpRequest; return this; } // 省略部分代码 ...... public <T> void execute(HttpCallBack<T> callback) { // 如果没有指定，那么就用 application 中初始化的 if(mHttpRequest == null){ mHttpRequest = mInitHttpRequest; } mHttpRequest.get(mContext, mParams, mUrl, mCache, callback); } }这个时候我们依赖的就已经不在是具体的细节了，而是抽象的 IHttpRequest ，具体的实现我们是在 Application 中配置的，可以配置 Okhttp 或者 xUtils 等等。从上面这几个来看要让整个系统更加灵活，似乎一直都是抽象的功劳。
接口隔离原则英文全称是InterfaceSegregation Principles，简称ISP。它的定义是：客户端不应该依赖它不需要的接口。另一种定义是：类间的依赖关系应该建立在最小的接口上。接口隔离原则将非常庞大、臃肿的接口拆分成为更小的和更具体的接口，这样客户将会只需要知道他们感兴趣的方法。接口隔离原则的目的是系统解开耦合，从而容易重构、更改和重新部署，让客户端依赖的接口尽可能地小。
拿我最近在做的一个项目来说，我用手机去调用相机拍照，源码我是没有的，后面想了很多办法把相机破解了，那么我获取到的数据后需及时传给后台，这个时候建立了一个 Socket 通信机制，我在 Activity 的 onDestory 中断开 Socket 连接我是这么写的：
/** * 中断链接 */ private void breakConnection() { mReadFlag = false; // 关闭输入流 if (mInStream != null) { try { mInStream.close(); } catch (IOException e) { e.printStackTrace(); } } // 关闭输出流 if (mOutStream != null) { try { mOutStream.close(); } catch (IOException e) { e.printStackTrace(); } } // 关闭Socket if (mSocket != null) { try { mSocket.close(); mSocket = null; } catch (Exception e) { e.printStackTrace(); } } }这段代码可能我们平时都这么写，各种try…catch嵌套，都是些简单的代码，但是会严重影响代码的可读性，并且多层级的大括号很容易将代码写到错误的层级中。大家应该对这类代码也非常反感，那我们看看如何解决这类问题。我们看源码发现他们都有一个 close 方法，而且这个方法是 Closeable 接口的，也就是说上面的这几个类都是实现了 Closeable 接口，该接口标识了一个可关闭的对象。这意味着，在关闭这一百多个类型的对象时，都需要写出上面这样的这些代码，而且并没有什么实际的意义。这还了得！既然有共性，那么我们可以再写一个方法：
/** * 中断链接 */ private void breakConnection() { mReadFlag = false; // 关闭输入流 close(mInStream); // 关闭输出流 close(mOutStream); // 关闭Socket close(mSocket); } /** * 关闭 Closeable * @param closeable */ private void close(Closeable closeable) { if (closeable != null) { try { closeable.close(); } catch (IOException e) { e.printStackTrace(); } } }代码简洁了很多！保证了代码的重用性。close 方法的基本原理就是依赖于 Closeable 抽象而不是具体实现（这其实也是依赖倒置），并且建立在最小化依赖原则的基础，它只需要知道这个对象是可关闭，其他的一概不关心，也就是这里的接口隔离原则。
Bob大叔（Robert C Martin）在21世纪早期将单一职责、开闭原则、里氏替换、接口隔离以及依赖倒置（也称为依赖反转）5个原则定义为SOLID原则，指代了面向对象编程的5个基本原则。当这些原则被一起应用时，它们使得一个软件系统更清晰、简单、最大程度地拥抱变化。SOLID被典型地应用在测试驱动开发上，并且是敏捷开发以及自适应软件开发基本原则的重要组成部分。在经过这一系列的学习之后，我们发现这几大原则最终就可以化为这几个关键词：抽象、单一职责、最小化。那么在实际开发过程中如何权衡、实践这些原则，是大家需要在实践中多思考与领悟，正所谓”学而不思则罔，思而不学则殆”，只有不断地学习、实践、思考，才能够在积累的过程有一个质的飞越。
最少知识原则又称为迪米特原则英文全称为Law of Demeter，简称LOD，虽然名字不同，但描述的是同一个原则：一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，类的内部如何实现、如何复杂都与调用者或者依赖者没关系，调用者或者依赖者只需要知道他需要的方法即可，其他的我一概不关心。类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
迪米特法则还有一个英文解释是：Only talk to your immedate friends，翻译过来就是：只与直接的朋友通信。什么叫做直接的朋友呢？每个对象都必然会与其他对象有耦合关系，两个对象之间的耦合就成为朋友关系，这种关系的类型有很多，例如组合、聚合、依赖等，这个我就不再做过多的讲解了。
末尾给大家推荐一本书《Android 源码设计模式》，不是给大家打广告，我也没拿任何好处。很多人一上来就要源代码，但是我的代码一直以来都是不会公开的，就算公开也是带着大家写的代码。我其实最想问的是代码真的就那么重要吗？OKhttp 自带缓存，之所要自己写缓存，是因为缓存其实也会分为很多种，比如我想把它先缓存到内存中，然后缓存到数据，接着缓存到磁盘，又或是我只想把他缓存到 SharedPreferences 我们可以借此机会练练手，当然这些我都不会在这里写了，根据上面的一些思想，相信你一定有办法把它写好。目前还不兼容 Retrofit ，这个我们必须得等看过 Retrofit 的源码过后才能做兼容。
最后提醒大家的是在应用开发过程中，最难的不是完成应用的开发工作，而是在后续的升级、维护过程中让应用系统能够拥抱变化。拥抱变化也就意味着在满足需求且不破坏系统稳定性的前提下保持高可扩展性、高内聚、低耦合，在经历了各版本的变更之后依然保持清晰、灵活、稳定的系统架构。当然，这是一个比较理想的情况，但我们必须要朝着这个方向去努力，那么遵循面向对象六大原则就是我们走向灵活软件之路所迈出的第一步。
所有分享大纲：Android进阶之旅 - 系统架构篇
视频讲解地址：http://pan.baidu.com/s/1dFdABLZ
