详解Java实践之适配器模式

一、前言

工作到3年左右很大一部分程序员都想提升自己的技术栈，开始尝试去阅读一些源码，例如spring、mybaits、dubbo等，但读着读着发现越来越难懂，一会从这过来一会跑到那去。甚至怀疑自己技术太差，慢慢也就不愿意再触碰这部分知识。

而这主要的原因是一个框架随着时间的发展，它的复杂程度是越来越高的，从最开始只有一个非常核心的点到最后开枝散叶。这就像你自己开发的业务代码或者某个组件一样，最开始的那部分核心代码也许只能占到20%，而其他大部分代码都是为了保证核心流程能正常运行的。所以这也是你读源码费劲的一部分原因。

框架中用到了设计模式吗？

框架中不仅用到设计模式还用了很多，而且有些时候根本不是一个模式的单独使用，而是多种设计模式的综合运用。与大部分小伙伴平时开发的crud可就不一样了，如果都是if语句从上到下，也就算得不上什么框架了。就像你到spring的源码中搜关键字adapter，就会出现很多实现类，例如；usercredentialsdatasourceadapter。而这种设计模式就是我们本文要介绍的适配器模式。

适配器在生活里随处可见

如果提到在日常生活中就很多适配器的存在你会想到什么？在没有看后文之前可以先思考下。

二、适配器模式介绍

适配器模式的主要作用就是把原本不兼容的接口，通过适配修改做到统一。使得用户方便使用，就像我们提到的万能充、数据线、mac笔记本的转换头、出国旅游买个插座等等，他们都是为了适配各种不同的口，做的兼容。。

除了我们生活中出现的各种适配的场景，那么在业务开发中呢？

在业务开发中我们会经常的需要做不同接口的兼容，尤其是中台服务，中台需要把各个业务线的各种类型服务做统一包装，再对外提供接口进行使用。而这在我们平常的开发中也是非常常见的。

三、案例场景模拟

随着公司的业务的不断发展，当基础的系统逐步成型以后。业务运营就需要开始做用户的拉新和促活，从而保障dau的增速以及最终roi转换。

而这时候就会需要做一些营销系统，大部分常见的都是裂变、拉客，例如；你邀请一个用户开户、或者邀请一个用户下单，那么平台就会给你返利，多邀多得。同时随着拉新的量越来越多开始设置每月下单都会给首单奖励，等等，各种营销场景。

那么这个时候做这样一个系统就会接收各种各样的mq消息或者接口，如果一个个的去开发，就会耗费很大的成本，同时对于后期的拓展也有一定的难度。此时就会希望有一个系统可以配置一下就把外部的mq接入进行，这些mq就像上面提到的可能是一些注册开户消息、商品下单消息等等。

而适配器的思想方式也恰恰可以运用到这里，并且我想强调一下，适配器不只是可以适配接口往往还可以适配一些属性信息。

3.1、场景模拟工程

itstack-demo-design-6-00

└── src

└── main

└── java

└── org.itstack.demo.design

├── mq

│ ├── create_account.java

│ ├── ordermq.java

│ └── poporderdelivered.java

└── service

├── orderservicejava

└── poporderservice.java

这里模拟了三个不同类型的mq消息，而在消息体中都有一些必要的字段，比如；用户id、时间、业务id，但是每个mq的字段属性并不一样。就像用户id在不同的mq里也有不同的字段：uid、userid等。同时还提供了两个不同类型的接口，一个用于查询内部订单订单下单数量，一个用于查询第三方是否首单。后面会把这些不同类型的mq和接口做适配兼容。

3.2、场景简述

3.2.1、注册开户mq

public class create_account {

    private string number;      // 开户编号
    private string address;     // 开户地
    private date accountdate;   // 开户时间
    private string desc;        // 开户描述

    // ... get/set     
}

3.2.2、内部订单mq

public class ordermq {

    private string uid;           // 用户id
    private string sku;           // 商品
    private string orderid;       // 订单id
    private date createordertime; // 下单时间     

    // ... get/set      
}

3.2.3、第三方订单mq

public class poporderdelivered {

    private string uid;     // 用户id
    private string orderid; // 订单号
    private date ordertime; // 下单时间
    private date sku;       // 商品
    private date skuname;   // 商品名称
    private bigdecimal decimal; // 金额

    // ... get/set      
}

3.2.4、查询用户内部下单数量接口

public class orderservice {

    private logger logger = loggerfactory.getlogger(poporderservice.class);

    public long queryuserordercount(string userid){
        logger.info("自营商家，查询用户的订单是否为首单：{}", userid);
        return 10l;
    }

}

3.2.5、查询用户第三方下单首单接口

public class poporderservice {

    private logger logger = loggerfactory.getlogger(poporderservice.class);

    public boolean isfirstorder(string uid) {
        logger.info("pop商家，查询用户的订单是否为首单：{}", uid);
        return true;
    }

}

以上这几项就是不同的mq以及不同的接口的一个体现，后面我们将使用这样的mq消息和接口，给它们做相应的适配。

四、代码实现

其实大部分时候接mq消息都是创建一个类用于消费，通过转换他的mq消息属性给自己的方法。

我们接下来也是先体现一下这种方式的实现模拟，但是这样的实现有一个很大的问题就是，当mq消息越来越多后，甚至几十几百以后，你作为中台要怎么优化呢？

4.1、工程结构

itstack-demo-design-6-01

└── src

└── main

└── java

└── org.itstack.demo.design

└── create_accountmqservice.java

└── ordermqservice.java

└── poporderdeliveredservice.java

目前需要接收三个mq消息，所有就有了三个对应的类，和我们平时的代码几乎一样。如果你的mq量不多，这样的写法也没什么问题，但是随着数量的增加，就需要考虑用一些设计模式来解决。

4.2、mq接收消息实现

public class create_accountmqservice {

    public void onmessage(string message) {

        create_account mq = json.parseobject(message, create_account.class);

        mq.getnumber();
        mq.getaccountdate();

        // ... 处理自己的业务
    }

}

三组mq的消息都是一样模拟使用，就不一一展示了。可以获取源码后学习。

五、适配器模式重构代码

接下来使用适配器模式来进行代码优化，也算是一次很小的重构。

适配器模式要解决的主要问题就是多种差异化类型的接口做统一输出，这在我们学习工厂方法模式中也有所提到不同种类的奖品处理，其实那也是适配器的应用。

在本文中我们还会再另外体现出一个多种mq接收，使用mq的场景。来把不同类型的消息做统一的处理，便于减少后续对mq接收。

在这里如果你之前没要开发过接收mq消息，可能听上去会有些不理解这样的场景。对此，我个人建议先了解下mq。另外就算不了解也没关系，不会影响对思路的体会。

再者，本文所展示的mq兼容的核心部分，也就是处理适配不同的类型字段。而如果我们接收mq后，在配置不同的消费类时，如果不希望一个个开发类，那么可以使用代理类的方式进行处理。

5.1、工程结构

itstack-demo-design-6-02

└── src

└── main

└── java

└── org.itstack.demo.design

├── impl

│ ├── insideorderservice.java

│ └── poporderadapterserviceimpl.java

├── mqadapter,java

├── orderadapterservice,java

└── rebateinfo,java

适配器模型结构

这里包括了两个类型的适配；接口适配、mq适配。之所以不只是模拟接口适配，因为很多时候大家都很常见了，所以把适配的思想换一下到mq消息体上，增加大家多设计模式的认知。
先是做mq适配，接收各种各样的mq消息。当业务发展的很快，需要对下单用户首单才给奖励，在这样的场景下再增加对接口的适配操作。

5.2、代码实现(mq消息适配)

5.2.1、统一的mq消息体

public class rebateinfo {

    private string userid;  // 用户id
    private string bizid;   // 业务id
    private date biztime;   // 业务时间
    private string desc;    // 业务描述
    
    // ... get/set
}

mq消息中会有多种多样的类型属性，虽然他们都有同样的值提供给使用方，但是如果都这样接入那么当mq消息特别多时候就会很麻烦。
所以在这个案例中我们定义了通用的mq消息体，后续把所有接入进来的消息进行统一的处理。

5.2.2、mq消息体适配类

public class mqadapter {

    public static rebateinfo filter(string strjson, map<string, string> link) throws nosuchmethodexception, invocationtargetexception, illegalaccessexception {
        return filter(json.parseobject(strjson, map.class), link);
    }

    public static rebateinfo filter(map obj, map<string, string> link) throws nosuchmethodexception, invocationtargetexception, illegalaccessexception {
        rebateinfo rebateinfo = new rebateinfo();
        for (string key : link.keyset()) {
            object val = obj.get(link.get(key));
            rebateinfo.class.getmethod("set" + key.substring(0, 1).touppercase() + key.substring(1), string.class).invoke(rebateinfo, val.tostring());
        }
        return rebateinfo;
    }

}

这个类里的方法非常重要，主要用于把不同类型mq种的各种属性，映射成我们需要的属性并返回。就像一个属性中有用户id;uid，映射到我们需要的；userid，做统一处理。
而在这个处理过程中需要把映射管理传递给map<string, string> link，也就是准确的描述了，当前mq中某个属性名称，映射为我们的某个属性名称。
最终因为我们接收到的mq消息基本都是json格式，可以转换为map结构。最后使用反射调用的方式给我们的类型赋值。

5.2.3、测试适配类

编写单元测试类

@test
public void test_mqadapter() throws nosuchmethodexception, illegalaccessexception, invocationtargetexception {
    create_account create_account = new create_account();
    create_account.setnumber("100001");
    create_account.setaddress("河北省.廊坊市.广阳区.大学里职业技术学院");
    create_account.setaccountdate(new date());
    create_account.setdesc("在校开户");          

    hashmap<string, string> link01 = new hashmap<string, string>();
    link01.put("userid", "number");
    link01.put("bizid", "number");
    link01.put("biztime", "accountdate");
    link01.put("desc", "desc");
    rebateinfo rebateinfo01 = mqadapter.filter(create_account.tostring(), link01);
    system.out.println("mq.create_account(适配前)" + create_account.tostring());
    system.out.println("mq.create_account(适配后)" + json.tojsonstring(rebateinfo01));

    system.out.println("");

    ordermq ordermq = new ordermq();
    ordermq.setuid("100001");
    ordermq.setsku("10928092093111123");
    ordermq.setorderid("100000890193847111");
    ordermq.setcreateordertime(new date()); 

    hashmap<string, string> link02 = new hashmap<string, string>();
    link02.put("userid", "uid");
    link02.put("bizid", "orderid");
    link02.put("biztime", "createordertime");
    rebateinfo rebateinfo02 = mqadapter.filter(ordermq.tostring(), link02);

    system.out.println("mq.ordermq(适配前)" + ordermq.tostring());
    system.out.println("mq.ordermq(适配后)" + json.tojsonstring(rebateinfo02));
}

在这里我们分别模拟传入了两个不同的mq消息，并设置字段的映射关系。
等真的业务场景开发中，就可以配这种映射配置关系交给配置文件或者数据库后台配置，减少编码。

测试结果

mq.create_account(适配前){“accountdate”:1591024816000,”address”:”河北省.廊坊市.广阳区.大学里职业技术学院”,”desc”:”在校开户”,”number”:”100001″}

mq.create_account(适配后){“bizid”:”100001″,”biztime”:1591077840669,”desc”:”在校开户”,”userid”:”100001″}

mq.ordermq(适配前){“createordertime”:1591024816000,”orderid”:”100000890193847111″,”sku”:”10928092093111123″,”uid”:”100001″}

mq.ordermq(适配后){“bizid”:”100000890193847111″,”biztime”:1591077840669,”userid”:”100001″}

process finished with exit code 0

从上面可以看到，同样的字段值在做了适配前后分别有统一的字段属性，进行处理。这样业务开发中也就非常简单了。
另外有一个非常重要的地方，在实际业务开发中，除了反射的使用外，还可以加入代理类把映射的配置交给它。这样就可以不需要每一个mq都手动创建类了。

5.3、代码实现(接口使用适配)

就像我们前面提到随着业务的发展，营销活动本身要修改，不能只是接了mq就发奖励。因为此时已经拉新的越来越多了，需要做一些限制。

因为增加了只有首单用户才给奖励，也就是你一年或者新人或者一个月的第一单才给你奖励，而不是你之前每一次下单都给奖励。

那么就需要对此种方式进行限制，而此时mq中并没有判断首单的属性。只能通过接口进行查询，而拿到的接口如下；

接口	描述
org.itstack.demo.design.service.orderservice.queryuserordercount(string userid)	出参long，查询订单数量
org.itstack.demo.design.service.orderservice.poporderservice.isfirstorder(string uid)	出参boolean，判断是否首单

两个接口的判断逻辑和使用方式都不同，不同的接口提供方，也有不同的出参。一个是直接判断是否首单，另外一个需要根据订单数量判断。
因此这里需要使用到适配器的模式来实现，当然如果你去编写if语句也是可以实现的，但是我们经常会提到这样的代码很难维护。

5.3.1、定义统一适配接口

public interface orderadapterservice {

    boolean isfirst(string uid);

}

后面的实现类都需要完成此接口，并把具体的逻辑包装到指定的类中，满足单一职责。

5.3.2、分别实现两个不同的接口

内部商品接口

public class insideorderservice implements orderadapterservice {

    private orderservice orderservice = new orderservice();

    public boolean isfirst(string uid) {
        return orderservice.queryuserordercount(uid) <= 1;
    }

}

第三方商品接口

public class poporderadapterserviceimpl implements orderadapterservice {

    private poporderservice poporderservice = new poporderservice();

    public boolean isfirst(string uid) {
        return poporderservice.isfirstorder(uid);
    }

}

在这两个接口中都实现了各自的判断方式，尤其像是提供订单数量的接口，需要自己判断当前接到mq时订单数量是否<= 1，以此判断是否为首单。

5.3.3、测试适配类