首页 > Python基础教程 >
-
(6)适配器模式
本笔记摘抄自：https://www.cnblogs.com/PatrickLiu/p/7640873.html，记录一下学习过程以备后续查用。
一、引言
从今天开始我们开始讲结构型设计模式，结构型设计模式有如下几种：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式。
创建型设计模式解决的是对象创建的问题，而结构型设计模式解决的是类和对象组合关系的问题。
今天我们开始讲结构型设计模式里面的第一个设计模式：适配器模式。适配器模式其实很简单，在现实生活中有很多这样的实例实例：比如，手机充电器的
接头是二插的，假如只有三插的插座，就必须通过三插转二插的转换器才可以正常充电；笔记本电脑的工作电压和家庭照明的电压是不一致的，需要通过变压
器（俗称火牛）才能让笔记本电脑正常工作。适配器的例子数不胜数，只需记住一点：适配就是转换，让不能在一起工作的两样东西通过转换可以正常工作。
二、适配器模式介绍
适配器模式：英文名称--Adapter Pattern；分类--结构型。
2.1、动机（Motivate）
在软件系统中，由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境中应用，但是新的环境要求的接口是这些现存对象所不能满足的。如何应
对这种“迁移的变化”？如何既能利用现有对象的良好实现，同时又能满足新的应用环境所要求的接口？
2.2、意图（Intent）
将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。--《设计模式》Gof
2.3、结构图（Structure）
适配器有两种结构：
1）对象适配器（更常用）
对象适配器使用的是对象组合的方案，它的Adapter和Adaptee的关系是组合关系。
OO中优先使用组合模式，组合模式不适用时再考虑继承，因为组合模式更加松耦合。而继承是紧耦合的，父类的任何改动都要导致子类的改动。
2）类适配器
2.4、模式的组成
从上两图可以看出，在适配器模式的结构图有以下角色：
1）目标角色（Target）：定义Client使用的与特定领域相关的接口。
2）客户角色（Client）：与符合Target接口的对象协同。
3）被适配角色（Adaptee)：定义一个已经存在并已经使用的接口，这个接口需要适配。
4）适配器角色（Adapter) ：适配器模式的核心，它将对被适配Adaptee角色已有的接口转换为目标角色Target匹配的接口并进行适配。
2.5 、适配器模式的具体实现
2.5.1对象适配器模式的实现
View Code运行结果如下：
2.5.2类适配器模式实现
View Code运行结果如下：
三、适配器模式的实现要点
1）Adapter模式主要应用于“希望复用一些现存的类，但是接口又与复用环境要求不一致的情况”，在遗留代码复用、类库迁移等方面非常有用。
2）GoF23定义了两种Adapter模式的实现结构：对象适配器和类适配器。类适配器采用“多继承”的实现方式，在C#语言中，如果被适配角色是类，Target的
实现只能是接口，因为C#语言只支持接口的多继承。在C#语言中类适配器也很难支持适配多个对象的情况，同时也会带来了不良的高耦合和违反类的单一职
责的原则，所以一般不推荐使用。对象适配器采用“对象组合”的方式，更符合松耦合精神，对适配的对象也没限制，可以一个也可以多个，但是，这也使得重
定义Adaptee的行为比较困难，这就需要生成Adaptee的子类并且使得Adapter引用这个子类而不是引用Adaptee本身。Adapter模式可以实现的非常灵活，不必
拘泥于GoF23中定义的两种结构。例如，完全可以将Adapter模式中的“现存对象”作为新的接口方法参数，来达到适配的目的。
3）Adapter模式本身要求我们尽可能地使用“面向接口的编程”风格，这样才能在后期很方便地适配。
下面详细总结下适配器两种形式的优缺点：
3.1、对象适配器模式
优点：
1）可以在不修改原有代码的基础上来复用现有类，很好地符合 “开闭原则”。
2）采用 “对象组合”的方式，更符合松耦合。
缺点：
1）使得重定义Adaptee的行为较困难，这就需要生成Adaptee的子类并且使得Adapter引用这个子类而不是引用Adaptee本身。
3.2、类适配器模式
优点：
1）可以在不修改原有代码的基础上来复用现有类，很好地符合 “开闭原则”。
2）可以重新定义Adaptee(被适配的类)的部分行为，因为在类适配器模式中，Adapter是Adaptee的子类。
3）仅仅引入一个对象，并不需要额外的字段来引用Adaptee实例（这个即是优点也是缺点）。
缺点：
1）用一个具体的Adapter类对Adaptee和Target进行匹配，当如果想要匹配一个类以及所有它的子类时，类的适配器模式就不能胜任了。因为类的适配器模
式中没有引入Adaptee的实例，光调用SpecificRequest方法并不能去调用它对应子类的SpecificRequest方法。
2）采用了 “多继承”的实现方式，带来了不良的高耦合。
3.3、适配器模式的使用场景
1）系统需要复用现有类，而该类的接口不符合系统的需求。
2）想要建立一个可重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作。
3）对于对象适配器模式，在设计里需要改变多个已有子类的接口，如果使用类的适配器模式，就要针对每一个子类做一个适配器，而这不太实际。
四、.NET中适配器模式的实现
说到适配器模式在.Net中的实现就很多了，比如：System.IO里面的很多类都有适配器的影子，当我们操作文件的时候，其实里面调用了COM的接口实现。
以下两点也是适配器使用的案例：
4.1、.NET中复用COM对象
COM对象不符合.NET对象的接口，使用tlbimp.exe来创建一个Runtime Callable Wrapper（RCW）以使其符合.NET对象的接口，COM Interop就好像是
COM和.NET之间的一座桥梁。
4.2、.NET数据访问类（Adapter变体）
各种数据库并没有提供DataSet接口，使用DbDataAdapter可以将任何数据库访问/存取适配到一个DataSet对象上，DbDataAdapter在数据库和DataSet之间
做了很好的适配。当然还有SqlDataAdapter类型，针对微软SqlServer类型的数据库在和DataSet之间进行适配。
五、总结
有一句话还是要说的，虽然以前说过。每种设计模式都有自己的适用场景，它是为了解决一类问题，没有所谓的缺点，没有一种设计模式可以解决所有情况
的。我们使用设计模式的态度是通过不断地重构来使用模式，不要一上来就使用设计模式，为了模式而模式。如果软件没有需求的变化，我们不使用模式都没
有问题。遇到问题，我们就按着常规来写，有了需求变化，然后我们去抽象，了解使用的场景，然后再选择合适的设计模式。
