接口隔离

最近接触了一个较大的项目，网络请求是这样的

NetworkManager.sendRequest(BaseRequest)

以Volley为核心封装的网络框架

存储、获取一些disk信息是这样的

DiskCacheManager.cache(Object)

以SharedPreference为核心封装的本地小型存取数据的框架

所有的网络，Disk缓存，图片加载等都不需要自己去写了，因为别人都写好了，我无须任何相关的知识就可以获得很强的对应的这些开发能力了

所以我第一时间的感觉是接口隔离，无须关心其实现，只需要知道它能给我带来什么

当然不是严格意义上的接口隔离，接口隔离是在做模块化的时候写个接口类把自己想暴露出去的API写在里面，解耦了调用者和实现类。

现在这个情况其实也差不多，不管这个图片框架底层是基于Glide封装还是Fresco封装，我只需要知道ImageLoader.getBitmap(url)可以获得Bitmap，这就够了

我感觉开发就得这么做，用最简单的API去进行调用，如果原生的某些框架满足不了，那就封装它。接口是在此基础上，定义更加严格的规约。

这样一来的好处是，我不用去鼓捣这些框架了，我所有的任务就是写业务了，这大大减少了我们的工作量，开发效率得到了质的提升。在接触这个项目以前，我没有特别体会到这一点，所有框架都需要鼓捣，甚至没有封装，每次都要重新写一次，对吧，比如SharedPreference，你是不是每次都要重新写一遍冗余的代码呢？这其中包含的对bug修复的再封装就不谈了。

不仅如此啊。为了深刻认识这一点，我还要提一下Glide。他的链式调用够简洁了吧？可是你链式调用去声明了以后，你会发现，当你想换一个框架的时候，无数的地方都需要改，所以Glide也需要被封装成getBitmap、loadImage诸如此类的大白话形式的api。这才是真正的理解！！

本文虽然基本没提接口，但是还是感觉讲出了接口隔离的真义。