编码中的Adapter，是一种设计模式，更是一种架构理念与解决方案

不知道下面这玩意大家有没有见过或者使用过？这是一个插座转换器。我们都知道日常使用的是220v的交流电，而国外不同国家使用的电流电压是不一样的（比如日本使用的是110v）、且插座的接口样式也是各不相同的（比如欧洲国家使用的是两个小圆柱状的插头接口），如果我们到别的国家去旅行的时候，借助这个插座转换器，就可以让我们的手机充电器在国外也能正常使用了。

当然，除了使用插座转换器，还有个方法也可以让我们出国之后正常的使用各种电子产品，那就是在当地重新买一套！显然，这样的成本就会非常巨大，明显不符合我们 勤（nang）俭（zhong）持（xiu）家（se） 的特征。

看过我前面的文章的小伙伴应该知道，我的文章中一直反复的在阐述自己的一个观念，即“编码源于生活” ，这里依旧不例外。现实生活中的朴素哲学思维，在代码世界中其实也无时无刻不在体现着。上面举的例子，在我们的项目中又何尝不是在频繁上演此类情况呢？

我们先按照原有的业务逻辑实现了一套代码，后来又来了个新的需求，如果重新开发一套需要投入大量的人力物力，所以首选方案就是去思考如何去复用已有的逻辑，以最小的代价将业务对接适配使用现有的逻辑去实现。

本篇文章中，我们就从这个“插座转换器”来作为切入点，聊一聊在软件系统中无处不在的“插座转换器” —— 编码中的适配器（Adapter）。选定以Adapter为题材进行阐述，并非是因为Adapter在技术实现上有多复杂，其实Adapter真正实现起来是非常简单的，而且很多人有意或无意中其实也都在使用。更多的是想一起探讨这种借助Adapter来复用与兼容已有逻辑的思路，以及如何利用Adapter来践行OCP（开闭原则）的系统架构设计理念。

Adapter的百媚千姿

新瓶旧酒：复用现成的实现逻辑

新瓶装旧酒，在我们的系统里面是一个很“节省”的操作，可以让我们基于一个现有的能力快速的封装提供出一个全新的业务功能，当然有的时候，系统现有的能力可能会某些方面无法完全满足新业务的需求，需要做一些转换适配处理。

举个例子：

一个视频网站，原先已有一个评论能力，用户可以在视频下方发表评论，然后评论内容以列表的形式展示在视频下方页面上。现在需要开发一个新功能，支持视频发送弹幕能力，并将弹幕显示在视频播放画面上。

从需求功能上来说，评论与弹幕有很多相似之处。对后端而言，其处理逻辑与存储数据结构几乎都是相同的，只是在数据列表API实现的时候，需要过滤出评论信息展示到评论区、或者过滤出弹幕信息显示到视频画面上。但是由于弹幕信息有一些特殊的属性，又没法直接完全使用现有的评论接口，比如弹幕可能会设置显示在屏幕的位置、弹幕的字体颜色等等。这种情况下，我们可以通过构造个Adapter适配器的方式，在复用已有评论能力的基础上，顺便扩展实现需要的弹幕新特性。