适配器模式又称封装器模式、Wrapper、Adapter
适配器模式是一种结构型设计模式, 它能使接口不兼容的对象能够相互合作
如下图所示:第三方分析函数库的入参只能接收JSON格式,而本地业务代码通过股票数据提供方查出来的数据是XML格式,因此需要一个适配器来进行参数的转换,达到顺利调用分析函数库的目的。
解决办法如下:
适配器的两种类型:
1.对象适配器
实现时使用了构成原则: 适配器实现了其中一个对象的接口, 并对另一个对象进行封装。
2.类适配器
这一实现使用了继承机制: 适配器同时继承(实现)两个对象的接口。 请注意, 这种方式仅能在支持多重继承的编程语言中实现,例如 C++,java。
适配器同时实现两个对象的接口:一个接口是已存在业务逻辑的接口A,另一个是需要调用的不兼容的接口B(可能为第三方服务之类的),适配器实现A接口和B接口,重写A接口的方法,在方法中进行参数的转换等适配操作调用接口B中的方法。
实现方式描述:
-
确保至少有两个类的接口不兼容:
- 一个无法修改 (通常是第三方、 遗留系统或者存在众多已有依赖的类) 的功能性服务类。
- 一个或多个将受益于使用服务类的客户端类。
-
声明客户端接口, 描述客户端如何与服务交互。
-
创建遵循客户端接口的适配器类。 所有方法暂时都为空。
-
在适配器类中添加一个成员变量用于保存对于服务对象的引用。 通常情况下会通过构造函数对该成员变量进行初始化, 但有时在调用其方法时将该变量传递给适配器会更方便。
-
依次实现适配器类客户端接口的所有方法。 适配器会将实际工作委派给服务对象, 自身只负责接口或数据格式的转换。
-
客户端必须通过客户端接口使用适配器。 这样一来, 你就可以在不影响客户端代码的情况下修改或扩展适配器。
优缺点:
优点:
- 单一职责原则_你可以将接口或数据转换代码从程序主要业务逻辑中分离。
- 开闭原则。 只要客户端代码通过客户端接口与适配器进行交互, 你就能在不修改现有客户端代码的情况下在程序中添加新类型的适配器。
缺点
- 代码整体复杂度增加, 因为你需要新增一系列接口和类。 有时直接更改服务类使其与其他代码兼容会更简单。