Retrofit的使用之设计模式

使用的设计模式有：

1. 动态代理
2. 门面模式

3. 适配器模式

   
   
   

   创建流程
   
   
   

   创建流程

创建Retrofit

1. 首先构造retrofit，几个核心的参数呢，主要就是baseurl,callFactory(默认okhttpclient),converterFactories,adapterFactories,excallbackExecutor。
2. 然后通过create方法拿到接口的实现类，这里利用Java的Proxy类完成动态代理的相关代理
3. 在invoke方法内部，拿到我们所声明的注解以及实参等，构造ServiceMethod，ServiceMethod中解析了大量的信息，最终可以通过toRequest构造出okhttp3.Request对象。有了okhttp3.Request对象就可以很自然的构建出okhttp3.call，最后calladapter对Call进行装饰返回。
4. 拿到Call就可以执行enqueue或者execute方法了

外观模式(门面模式)

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

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

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

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

动态代理

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

适配器模式

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