Rettrofit设计模式

外观模式(门面模式)

Retrofit给我们暴露的方法和类不多。核心类就是Retrofit，我们只管配置Retrofit，然后做请求。剩下的事情就跟上层无关了，只需要等待回调。这样大大降低了系统的耦合度。对于这种写法，我们叫外观模式(门面模式)。

几乎所有优秀的开源library都有一个门面。比如Glide.with() ImageLoader.load() Alamofire.request()。有个门面方便记忆，学习成本低，利于推广品牌。 Retrofit的门面就是retrofit.create()

当我们自己写的代码的时候尽量也要这样来做。
比如我们有一个独立并公用的模块，需要供其他模块来调用。比如download，location，socialshare等

最好我们写一个module，将所有相关的代码都放在这个module中。这是第一步。
第二步，为你的module提供一个漂亮的门面。比如下载的DownloadManager, 经纬度的LocationTracker, 社交分享的SocialManager。它们做为功能模块的入口，要尽量的简洁，方法命名好记易理解，类上要有完整的示例注释
第三步，闭门造车。不管你在里面干什么，外面都是不知道的，就像薛定谔的那只猫，外层不调用它，永远不知道它是否好用。
不过为了以后好维护，不给他人留坑，还是尽量写的工整一些。

动态代理

Retrofit里的动态代理比较巧妙。实际上它根本就没有delegate。因为这个方法没有真正的实现。使用动态代理，只是单纯的为了拿到这个method上所有的注解。所有的工作都是由proxy做了，上面创建Retrofit的地方有说如何使用Java 的Proxy类来实现动态代理的。

适配器模式

将OkHttpCall转换成rxjava(Scheduler)的写法。再后来又支持了java8(CompletableFuture)甚至居然还有iOS支持。大概就是这样一个套路。当然我相信square的大神肯定一开始就考虑了这种情况，从而设计了CallAdapter。
适配器模式就是，已经存在的OkHttpCall，要被不同的标准，平台来调用。设计了一个接口CallAdapter，让其他平台都是做不同的实现来转换，这样不花很大的代价就能再兼容一个平台。