今天要讲的设计模式堪称人人都会，不是因为它太简单，而是因为它太常见，它就是 适配器模式

这个玩意大家应该都认识，它是一个耳机转接头

假如你只有一个圆孔插头的耳机，但是手机的音频插口是type-c的，这时候你是没办法用耳机听歌的

利用耳机转接头，就可以使用圆孔的插头和type-c插口的手机来听歌

在我们对接一个三方系统时，假如我们系统的接口规范和三方系统的接口规范不一样，该怎么对接

接口规范不一致，导致我们不能和三方系统完成对接，必须修改其中一方的接口规范

但是，不管修改哪一方的接口规范都可能导致系统已有的功能不能正常使用

让我们发挥想象，把我们系统比作是圆孔耳机，把三方系统比作是type-c插口的手机。我们只需要一个「耳机转接头」就可以完成两个系统的对接，而且不需要修改任何一方的代码

这里的「耳机转接头」的作用就是把我们系统的接口规范转换成三方系统的接口规范，让两个系统都不需要修改代码就可以完成无缝对接

仔细想想一下，在我们的实际工作中，是不是经常做「耳机转接头」这样的工作

实际上，「耳机转接头」就是一个适配器，这就是一个简单的「适配器模式」

系统间的调用会用到适配器模式，代码直接的调用也会用到适配器模式

使用场景

在两个功能间无法完成无缝对接，必须要修改其中一处功能，但是修改工作量较大或者担心修改完造成已有功能无法使用时，可以考虑使用适配器模式

适配器模式的识别方法：「当一个方法的入参是一个对象，而返回值是另一个对象时，这个方法就是一个适配器模式」

比如，java中的 java.util.Arrays#asList()

这个方法的作用是把一个数组转换成list集合。数组和list属于两个不同的类，没办法完成无缝转换

这时候就需要这个方法来进行「适配」，它的入参是一个任意类型的数组对象，返回值是一个list对象，符合上面我们说的适配器模式的识别方法，所以这个方法就是一个适配器模式

实际案例

假如我们有一个接口，需要统计用户最近购买的商品信息并返回给前台

查询数据库的方法已经封装好，返回的数据格式如下

前台要求返回的数据格式如下

我们先来用代码模拟一下从数据库查询数据的逻辑

这里需要一个实体类，用来对应数据库查询出来的数据

用代码模拟从数据库查询出5条数据

再来模拟一下前台要求的数据格式

这里需要两个实体类对应前台要求的数据格式

用代码来模拟一下实际给前台返回数据的逻辑

从数据库查询出来的数据和前台要求的数据都用代码模拟出来了，那么该怎么把从数据库查询出来的格式转换成前台需要的格式？

也就是说要怎么把List<UserProductInfo>对象转换成List<UserProductInfoRsp>对象？

修改查询数据库的方法逻辑显然不合适，作为DAO层对所有业务提供通用的查询数据库的能力，修改后会导致其他调用该方法的业务报错

修改前台数据格式也不合适，前台开发模式是一云多端的模式，不可能让所有端的前台都跟着修改代码

所以，该适配器模式出场啦

我们需要定义一个方法，方法的入参是List<UserProductInfo>，方法的返回值是List<UserProductInfoRsp>，在这个方法中完成两个对象的转换

ps：该方法的业务逻辑稍微有点复杂，感兴趣的同学可以看一下。不愿意看也行，只看方法的入参和返回值也不影响对适配器模式的理解

这样我们就用适配器模式完成了两个对象的转换，而且两方的业务逻辑都不需要修改，堪称“完美”

总结

适配器模式又被称为包装模式或封装器模式

当两个功能间无法完成无缝对接，必须要修改其中一处功能，但是修改工作量较大或者担心修改完造成已有功能无法使用时，可以考虑使用适配器模式

「适配器模式的优点」

• 解耦：适配器将两个功能完全解耦，从而达到不需要修改任何一方的原有逻辑的目的
• 提高代码复用性：适配的两方不需要修改任何逻辑，可以更专注自己本身的业务逻辑，对外提供更通用的能力，使代码的复用性更好
• 提高系统的扩展性：可以通过各种适配器，对已有的功能或系统进行适配，让其能适应更多的场景，使自己的功能或系统扩展性更高

「适配器模式的缺点」

• 造成系统结构混乱：过多的使用适配器，会造成系统过于庞大且混乱不利于系统维护

学会设计模式不是目的，理解设计模式隐含的设计思想才能无往不利

「技术需要沉淀，我们下期再见」

-- 以上内容来自公众号「赫连小伍」