感概
成为一个程序员这么多年来，对于适配器模式的理解一直都处于一知半解的程度。每次在面试之前，都会慌慌张张的在搜索引擎上面搜索什么是适配器模式，然后看着也许两年以前早就看过一遍的文章又读一遍，看完之后，每一次不出意外都是一样的感受。每个字都看懂了，但是又好像啥也不懂。带着这样的感受，等着来年再来看一遍。。 。
而前两天在工作中感觉似乎有点摸到门道了，于是赶紧记录一下，避免重蹈覆辙。
本篇文章将会按照以下的步骤来进行分享
- 适配器模式的定义
- 为什么适配器模式不好理解(个人看法)
- 我是怎么突然有所理解的呢
- 为什么叫做适配器模式
适配器模式的定义
1.它主要用于在不改变现有系统结构的情况下，将一个类的接口转换成客户端所期望的另一个接口
2.当接口无法和类匹配到一起工作时，通过适配器将接口变换成可以和类匹配到一起的接口。
以上是我在搜索引擎中找到的一些对于适配器模式的解释，在我看来都非常的抽象。(明明看懂了每一个字，但是又好像啥也不懂的感觉此时再度涌上心头)
为什么适配器模式不好理解(个人看法)
所以为什么会出现这种不好理解的情况呢。在我看来是因为缺乏实际的应用场景。在搜索引擎上面遍地充斥的讲解适配器模式的文章都是大同小异。先给你举一个USB转接头的例子，然后告诉我们适配器模式有三个角色，目标接口（Target），适配器（Adapter），被适配者（Adaptee），之后就是写一个demo代码来告诉我们实际的用法，不过可能是我真的悟性比较差，每次看到这样的例子很难想象到如何在工作中运用到这种模式，反而还觉得这写法花里胡哨到底是在干嘛？
我是怎么突然有所理解的呢
那么书归正传，吐槽了一大堆，现在说一下我是怎么突然get到适配器模式的用处的呢？
其实我能突然有所了解，还是因为另一篇文章，关于如何在spring下优雅的实现策略模式。
spring中愉快的使用策略模式
只能说很神奇，我在讲解策略模式的文章中，对于适配器模式有了更多的理解。
要说适配器模式，我想先从策略模式开始。
策略场景:
例如现在我们要实现一个路由的策略，策略有轮询，有随机，也有权重。 我们要根据外部配置，选相对应的策略，获取到目标服务器的地址。
那么我们就会定义一个路由策略的接口，并且写三个实现类，分别对应轮询，随机，权重，各自实现了路由策略的getPath的接口方法。然后在使用的时候，就是根据配置获取到了对应的策略实现类，调用了getPath方法获取到了目标服务器。这就是一个比较典型的策略模式的运用，具体的使用可以参照上面这个文章。
现在终于轮到今天的主角，适配器模式登场了。
适配器场景
例如我们现在有一个财务系统的开发需求，这个需求是要使用不同的第三方进行开票。
比如，我们现在有金蝶财务软件开票，用友财务软件开票，鼎捷财务软件开票。这三家都提供了对应的api,例如
金蝶是
JDResult result = jDHttpTemplate.billingJD(String param1)
用友是
NCResult result = nCHttpTemplate.billingNC(String param1,String param2)
鼎捷是
DJResult result = dJHttpTemplate.billingDJ(String param1,String param2，String param3)
可以发现三个方法的入参和出参都是不一样的。正常最low的写法就是if-else，根据当前使用的财务软件，去调用各自的api方法，还得去处理各自不同的返回值，一旦任何一个三方有所变化，代码就得相应的变化。很明显这违反了单一原则和开闭原则。怎么办呢，这时候就是要让主角登场了。
我们可以这样来设计代码
定义一个接口，这就是适配器模式中的 target接口
interface BillingAdapterInterface{
public CustomResult billing(CustomParam param);
}
定义一个金蝶的适配器
public class JDBillingAdapter implements BillingAdapterInterface{
public CustomResult billing(CustomParam param){
//具体逻辑
.....
}
}
定义一个用友的适配器
public class NCBillingAdapter implements BillingAdapterInterface{
public CustomResult billing(CustomParam param){
//具体逻辑
.....
}
定义一个鼎捷的适配器
public class DJBillingAdapter implements BillingAdapterInterface{
public CustomResult billing(CustomParam param){
//具体逻辑
.....
}
OK了，那么三个角色中的target和Adapter都已经有了，Adaptee在哪里呢。其实早就已经出现了，就是jDHttpTemplate，nCHttpTemplate和dJHttpTemplate，这些就是被适配的接口了。ok，那么现在我们就已经将完全不相同的三个三方财务软件的开票接口都适配成了BillingAdapterInterface的billing方法。接下来怎么使用这个适配器呢，大家有没有感觉到熟悉，没错，就是和上面的策略模式很相似，同样的方式。如此一来，在我们的业务代码中，就可以通过一些手段拿到你想要使用的适配器，然后调用billing方法来开票了
//大致是这样一个使用方式
BillingAdapterInterface adapter = BillingAdapterfactory.getAdapter(xxx);
CustomResult result = adapter.billing(CustomParam param);
如此一来，就没有烦人恶心的if-else了，相比较而言代码是不是整洁干净了很多。
当然整洁干净只是最基本的一个好处。不知道大家是否有了解过DDD架构模式。在DDD架构模式中，有一个非常好的设计思想，就是ACL(防腐层)，而适配器就是ACL一个非常常见的实现方式了。
在这段业务代码中，由于我们进行了防腐设计，三方的接口的变动，不会影响到我们主题的业务代码。比如入参和出参有所变化也不会影响到业务代码，你需要修改的仅仅是对应的适配器中的逻辑。将变更的污染限制在了适配器中。
为什么叫做适配器模式
那么现在，大家应该都对为什么叫做适配器模式有所了解了吧，通过我们的设计，我们将各自不同的三方财务软件的开票接口，全都适配到了我们自己定义的billing中。
