【再谈设计模式】适配器模式 ~接口兼容的桥梁
一、引言
在软件开发的复杂世界里,不同的组件、类或者系统往往有着各自独立的设计和接口定义。当需要将这些原本不兼容的部分整合在一起协同工作时,就像尝试将方形的榫头插入圆形的卯眼一样困难。适配器设计模式就如同一位神奇的工匠,能够巧妙地解决这个问题,让不同接口之间实现无缝对接。
二、定义与描述
适配器设计模式属于结构型设计模式。它的主要作用是将一个类的接口转换为另一个接口,使原本由于接口不兼容而不能一起工作的类能够协同工作。可以把适配器想象成一个中间件,它包裹着一个已有的类,对外提供一个符合目标需求的新接口。
三、抽象背景
在大型软件项目中,往往会集成多个不同的库或者模块。这些模块可能是由不同的团队开发,或者是在不同的时期基于不同的需求开发的。每个模块都有自己的接口设计,当需要将它们组合使用时,就会出现接口不匹配的情况。例如,一个旧的数据库访问模块可能提供了一种特定的查询接口,而新的业务逻辑层需要一种不同格式的查询结果。这时候就需要适配器来协调两者之间的差异。
四、适用场景与现实问题解决
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;
}
@Override
public 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 = adaptee
def request(self):
self.adaptee.specific_request()
if __name__ == "__main__":
adaptee = Adaptee()
target = Adapter(adaptee)
target.request()
Go示例
package main
import "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库的接口下工作,就可以使用双向适配器。
对象适配器和类适配器的混合使用
在某些复杂的场景下,可以结合对象适配器(使用对象组合来实现适配)和类适配器(使用继承来实现适配)的优点。例如,先通过类适配器继承一些基本的功能,再通过对象组合来实现更灵活的适配。这种混合方式可以根据具体的需求,在代码复用性、灵活性和性能之间取得更好的平衡。