意图   将一个类的接口转换成客户希望的另外一个接口。 Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。 适配器这个名称非常好，读者可以考虑电源插头转换器，接下来我们会不断地重复这个类比。   动机   有时，为复用而设计的工具箱类不能够被复用的原因仅仅是因为它的接口与专业应用领域所需要的接口不匹配。   提供一个可以复用的类库或者函数库一般来讲并不是一个很难的事情，难的是无法预知将来的使用方式，也就是说无法为将来准备接口。也就是说，当我们使用已有类库的时候，接口一般都不会正好和我们的需求想匹配。   例如，有一个绘图编辑器，这个编辑器允许用户绘制和排列基本图元（线、多边型和正文等）生成图片和图表。这个绘图编辑器的关键抽象是图形对象。图形对象有一个可编辑的形状，并可以绘制自身。图形对象的接口由一个称为Shape的抽象类定义。绘图编辑器为每一种图形对象定义了一个Shape的子类：LineShape类对应于直线，PolygonShape类对应于多边型，等等。   假设有要开发一个图形编辑器，可以支持各种图形的编辑。   像LineShape和PolygonShape这样的基本几何图形的类比较容易实现，这是由于它们的绘图和编辑功能本来就很有限。但是对于可以显示和编辑正文的TextShape子类来说，实现相当困难，因为即使是基本的正文编辑也要涉及到复杂的屏幕刷新和缓冲区管理。同时，成品的用户界面工具箱可能已经提供了一个复杂的TextView类用于显示和编辑正文。理想的情况是我们可以复用这个 TextView类以实现TextShape类，但是工具箱的设计者当时并没有考虑Shape的存在，因此TextView和Shape对象不能互换。   开发任何一个具有一定规模软件，总会有些功能要在自己实现和使用已有代码之间选择。而这个选择的结果一般受到几个因素的影响：首先自己实现的难度，如实现比较简单，一般都会选择自己实现，虽然要花一点时间，但是程序员可以掌控一切。如果实现很困难，就会考虑使用现有类库等。一般来说引用其他的库就意味着编译条件的复杂化，调试的复杂化等问题。理所当然，使用的类库不会正好具有我们需要的接口。   一个应用可能会有一些类具有不同的接口并且这些接口互不兼容，在这样的应用中象TextView这样已经存在并且不相关的类如何协同工作呢？我们可以改变 TextView类使它兼容Shape类的接口，但前提是必须有这个工具箱的源代码。然而即使我们得到了这些源代码，修改TextView也是没有什么意义的；因为不应该仅仅为了实现一个应用，工具箱就不得不采用一些与特定领域相关的接口。   当我们需要使用的类库不具有我们希望的接口时应该怎么做呢？如果已有类库是我们自己的代码，就会有相当比例的开发者会选择修改已有库的接口以适用新用法。这并不是一个明智的做法：因为这会造成代码的重复，不符合DRY（Don't Repeat Yourself）原则。   我们可以不用上面的方法，而定义一个TextShape类，由它来适配TextView的接口和Shape的接口。我们可以用两种方法做这件事： 1) 继承S h a p e类的接口和TextView的实现，或2) 将一个TextView实例作为TextShape的组成部分，并且使用TextView的接口实现TextShape。这两种方法恰恰对应于Adapter模式的类和对象版本。我们将TextShape称之为适配器Adapter。   推荐的方法是定义一个中间层，从接口的角度来讲，它复合新软件的架构需求，它就是一个新架构下的一个普通子类，具备所需的接口；从实现的角度来讲，它使用已有类库的功能，不需要从头实现。这里使用已有库的方法两个：一个是IS A方式，即继承的方式；另一个是HAS A方式机组合的方式。这两种方式差不多使面向对象设计永远的话题，目前的趋势是使用组合的方式。但是无论哪种方式，都属于适配器模式。   作者观点   想象一下，海淘回来一个喜欢的苹果笔记本，回家一看，电源插头插不到家里的插座里，这式你会怎么办？一般情况下，你不会更换墙上的插座或者笔记本电源的插头，因为你舍不得。更简单，更现实的做法是再另外买一个转换器。这其实也就是适配器模式的想法。   注：   本文中蓝 {MOD}粗体文字都引自《设计模式》一书。   觉得本文有帮助？请分享给更多人。 阅读更多更新文章，请扫描下面二维码，关注微信公众号【面向对象思考】