【再谈设计模式】适配器模式 ~接口兼容的桥梁

一、引言

        在软件开发的复杂世界里，不同的组件、类或者系统往往有着各自独立的设计和接口定义。当需要将这些原本不兼容的部分整合在一起协同工作时，就像尝试将方形的榫头插入圆形的卯眼一样困难。适配器设计模式就如同一位神奇的工匠，能够巧妙地解决这个问题，让不同接口之间实现无缝对接。

二、定义与描述

        适配器设计模式属于结构型设计模式。它的主要作用是将一个类的接口转换为另一个接口，使原本由于接口不兼容而不能一起工作的类能够协同工作。可以把适配器想象成一个中间件，它包裹着一个已有的类，对外提供一个符合目标需求的新接口。

三、抽象背景

        在大型软件项目中，往往会集成多个不同的库或者模块。这些模块可能是由不同的团队开发，或者是在不同的时期基于不同的需求开发的。每个模块都有自己的接口设计，当需要将它们组合使用时，就会出现接口不匹配的情况。例如，一个旧的数据库访问模块可能提供了一种特定的查询接口，而新的业务逻辑层需要一种不同格式的查询结果。这时候就需要适配器来协调两者之间的差异。

四、适用场景与现实问题解决

1、适用场景

集成第三方库
        当使用第三方库时，其接口可能与项目中的其他部分不兼容。例如，一个图形绘制库的坐标系统与项目中自定义的坐标系统不同，通过适配器可以将两者协调起来。
旧系统升级
        在对旧系统进行升级时，新的模块可能采用了新的接口标准。使用适配器模式可以让旧系统中的部分继续使用，而不必对旧系统进行大规模的重写。
多平台适配

        对于需要在不同平台（如Windows、Linux、Mac）上运行的软件，不同平台可能有不同的API。适配器可以将不同平台的API转换为统一的接口，使业务逻辑层能够在不同平台上无缝运行。

2、现实问题解决

        假设一个公司收购了另一家公司，被收购公司有一套已经开发好的用户认证系统。收购公司的主系统有自己的用户认证接口，通过适配器模式，可以将被收购公司的用户认证系统适配到收购公司的主系统中，避免重新开发用户认证功能，节省时间和成本。

五、现实生活的例子

1、电源适配器

        不同国家的电源插座标准不同，如中国的插座是扁头的，而一些国外的电器插头可能是圆头的。电源适配器就起到了接口转换的作用，它可以将国内的电源接口转换为适合国外电器使用的接口，反之亦然。

2、手机充电器转接头

        新的手机可能采用了新的充电接口标准，但是旧的充电器仍然可以使用，只需要一个转接头（适配器），将旧充电器的接口转换为新手机能够接受的接口。

六、初衷与问题解决

        初衷是为了提高软件的可复用性和灵活性。在面对接口不兼容的情况时，不必修改原有的类或模块，通过适配器可以快速地解决接口匹配问题，降低了代码的耦合度，使得系统更容易维护和扩展。

七、代码示例

Java示例

// 目标接口
interface Target {void request();
}// 被适配的类
class Adaptee {public void specificRequest() {System.out.println("Adaptee's specific request");}
}// 适配器类
class Adapter implements Target {private Adaptee adaptee;public Adapter(Adaptee adaptee) {this.adaptee = adaptee;}@Overridepublic void request() {adaptee.specificRequest();}
}public class Main {public static void main(String[] args) {Adaptee adaptee = new Adaptee();Target target = new Adapter(adaptee);target.request();}
}

C++示例

#include <iostream>// 目标类（抽象类）
class Target {
public:virtual void request() = 0;virtual ~Target() {}
};// 被适配的类
class Adaptee {
public:void specificRequest() {std::cout << "Adaptee's specific request" << std::endl;}
};// 适配器类
class Adapter : public Target {
private:Adaptee* adaptee;
public:Adapter(Adaptee* adaptee) : adaptee(adaptee) {}void request() override {adaptee->specificRequest();}~Adapter() {delete adaptee;}
};int main() {Adaptee* adaptee = new Adaptee();Target* target = new Adapter(adaptee);target.request();delete target;return 0;
}

Python示例

# 目标接口
class Target:def request(self):pass# 被适配的类
class Adaptee:def specific_request(self):print("Adaptee's specific request")# 适配器类
class Adapter(Target):def __init__(self, adaptee):self.adaptee = adapteedef request(self):self.adaptee.specific_request()if __name__ == "__main__":adaptee = Adaptee()target = Adapter(adaptee)target.request()

Go示例

package mainimport "fmt"// 目标接口
type Target interface {request()
}// 被适配的类
type Adaptee struct{}func (a *Adaptee) specificRequest() {fmt.Println("Adaptee's specific request")
}// 适配器结构体
type Adapter struct {adaptee *Adaptee
}func (a *Adapter) request() {a.adaptee.specificRequest()
}func main() {adaptee := &Adaptee{}target := &Adapter{adaptee: adaptee}target.request()
}

八、适配器设计模式的优缺点

优点

提高了代码的复用性
        可以复用现有的类，而不需要修改它们的代码。通过适配器将其适配到新的接口下，就可以在新的场景中使用。
降低了代码的耦合度
        被适配的类和使用适配后接口的类之间不需要直接交互，它们通过适配器进行通信。这样，当其中一方发生变化时，只要适配器的逻辑不变，另一方就不需要修改。
灵活性好
        可以很容易地替换适配器或者被适配的类，只要遵循相应的接口规范。

缺点

增加了代码的复杂性
        如果过多地使用适配器模式，会使得代码结构变得复杂，增加了理解和维护的难度。因为需要理解适配器、被适配的类以及目标接口之间的关系。
可能会降低性能
        由于适配器在中间做了一层转换，可能会对性能产生一定的影响，尤其是在对性能要求极高的场景下。

九、适配器设计模式的升级版

双向适配器

        普通的适配器是单向的，即从被适配的类转换到目标接口。双向适配器则可以实现双向的转换，既能将被适配类转换为目标接口，也能将符合目标接口的对象转换为被适配类的接口。例如，在两个不同的库之间，不仅要让A库能在B库的接口下工作，也要让B库能在A库的接口下工作，就可以使用双向适配器。

对象适配器和类适配器的混合使用

        在某些复杂的场景下，可以结合对象适配器（使用对象组合来实现适配）和类适配器（使用继承来实现适配）的优点。例如，先通过类适配器继承一些基本的功能，再通过对象组合来实现更灵活的适配。这种混合方式可以根据具体的需求，在代码复用性、灵活性和性能之间取得更好的平衡。