适配器模式（Adapter Pattern）
——.NET设计模式系列之八
Terrylee，2006年2月
概述
在软件系统中，由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。那么如何应对这种“迁移的变化”？如何既能利用现有对象的良好实现，同时又能满足新的应用环境所要求的接口？这就是本文要说的Adapter 模式。
意图
将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
结构图
图1 类的Adapter模式结构图
图2 对象的Adapter模式结构图
生活中的例子
适配器模式允许将一个类的接口转换成客户期望的另一个接口，使得原本由于接口不兼容而不能一起工作的类可以一起工作。扳手提供了一个适配器的例子。一个孔套在棘齿上，棘齿的每个边的尺寸是相同的。在美国典型的边长为1/2''和1/4''。显然，如果不使用一个适配器的话，1/2''的棘齿不能适合1/4''的孔。一个1/2''至1/4''的适配器具有一个1/2''的阴槽来套上一个1/2''的齿，同时有一个1/4的阳槽来卡入1/4''的扳手。
图3使用扳手适配器例子的适配器对象图
适配器模式解说
我们还是以日志记录程序为例子说明Adapter模式。现在有这样一个场景：假设我们在软件开发中要使用一个第三方的日志记录工具，该日志记录工具支持数据库日志记录DatabaseLog和文本文件记录FileLog两种方式，它提供给我们的API接口是Write()方法，使用方法如下：
Log.Write("Logging Message!");
当软件系统开发进行到一半时，处于某种原因不能继续使用该日志记录工具了，需要采用另外一个日志记录工具，它同样也支持数据库日志记录DatabaseLog和文本文件记录FileLog两种方式，只不过它提供给我们的API接口是WriteLog()方法，使用方法如下：
Log.WriteLog("Logging Message!");
该日志记录工具的类结构图如下：
图4日志记录工具类结构图
它的实现代码如下：
public abstract class LogAdaptee
{
public abstract void WriteLog();
}
public class DatabaseLog:LogAdaptee
{
public override void WriteLog()
{
Console.WriteLine("Called WriteLog Method");
}
}
public class FileLog:LogAdaptee
{
public override void WriteLog()
{
Console.WriteLine("Called WriteLog Method");
}
}
在我们开发完成的应用程序中日志记录接口中（不妨称之为ILogTarget接口，在本例中为了更加清楚地说明，在命名上采用了Adapter模式中的相关角色名字），却用到了大量的Write()方法，程序已经全部通过了测试，我们不能去修改该接口。代码如下：
public interface ILogTarget
{
void Write();
}
这时也许我们会想到修改现在的日志记录工具的API接口，但是由于版权等原因我们不能够修改它的源代码，此时Adapter模式便可以派上用场了。下面我们通过Adapter模式来使得该日志记录工具能够符合我们当前的需求。
前面说过，Adapter模式有两种实现形式的实现结构，首先来看一下类适配器如何实现。现在唯一可行的办法就是在程序中引入新的类型，让它去继承LogAdaptee类，同时又实现已有的ILogTarget接口。由于LogAdaptee有两种类型的方式，自然我们要引入两个分别为DatabaseLogAdapter和FileLogAdapter的类。
图5 引入类适配器后的结构图
实现代码如下：
public class DatabaseLogAdapter:DatabaseLog,ILogTarget
{
public void Write()
{
WriteLog();
}
}
public class FileLogAdapter:FileLog,ILogTarget
{
public void Write()
{
this.WriteLog();
}
}
这里需要注意的一点是我们为每一种日志记录方式都编写了它的适配类，那为什么不能为抽象类LogAdaptee来编写一个适配类呢？因为DatabaseLog和FileLog虽然同时继承于抽象类LogAdaptee，但是它们具体的WriteLog()方法的实现是不同的。只有继承于该具体类，才能保留其原有的行为。
我们看一下这时客户端的程序的调用方法：
public class App
{
public static void Main()
{
ILogTarget dbLog = new DatabaseLogAdapter();
dbLog.Write("Logging Database...");
ILogTarget fileLog = new FileLogAdapter();
fileLog.Write("Logging File...");
}
}
下面看一下如何通过对象适配器的方式来达到我们适配的目的。对象适配器是采用对象组合而不是使用继承，类结构图如下：
图6引入对象适配器后的结构图
实现代码如下：
public class LogAdapter:ILogTarget
{
private LogAdaptee _adaptee;
public LogAdapter(LogAdaptee adaptee)
{
this._adaptee = adaptee;
}
public void Write()
{
_adaptee.WriteLog();
}
}
与类适配器相比较，可以看到最大的区别是适配器类的数量减少了，不再需要为每一种具体的日志记录方式来创建一个适配器类。同时可以看到，引入对象适配器后，适配器类不再依赖于具体的DatabaseLog类和FileLog类，更好的实现了松耦合。
再看一下客户端程序的调用方法：
public class App
{
public static void Main()
{
ILogTarget dbLog = new LogAdapter(new DatabaseLog());
dbLog.Write("Logging Database...");
ILogTarget fileLog = new LogAdapter(new FileLog());
fileLog.Write("Logging Database...");
}
}
通过Adapter模式，我们很好的实现了对现有组件的复用。对比以上两种适配方式，可以总结出，在类适配方式中，我们得到的适配器类DatabaseLogAdapter和FileLogAdapter具有它所继承的父类的所有的行为，同时也具有接口ILogTarget的所有行为，这样其实是违背了面向对象设计原则中的类的单一职责原则，而对象适配器则更符合面向对象的精神，所以在实际应用中不太推荐类适配这种方式。再换个角度来看类适配方式，假设我们要适配出来的类在记录日志时同时写入文件和数据库，那么用对象适配器我们会这样去写：
public class LogAdapter:ILogTarget
{
private LogAdaptee _adaptee1;
private LogAdaptee _adaptee2;
public LogAdapter(LogAdaptee adaptee1,LogAdaptee adaptee2)
{
this._adaptee1 = adaptee1;
this._adaptee2 = adaptee2;
}
public void Write()
{
_adaptee1.WriteLog();
_adaptee2.WriteLog();
}
}
如果改用类适配器，难道这样去写：
public class DatabaseLogAdapter:DatabaseLog,FileLog,ILogTarget
{
public void Write()
{
//WriteLog();
}
}
显然是不对的，这样的解释虽说有些牵强，也足以说明一些问题，当然了并不是说类适配器在任何情况下都不使用，针对开发场景不同，某些时候还是可以用类适配器的方式。
.NET中的适配器模式
1．Adapter模式在.NET Framework中的一个最大的应用就是COM Interop。COM Interop就好像是COM和.NET之间的一条纽带，一座桥梁。我们知道，COM组件对象与.NET类对象是完全不同的，但为了使COM客户程序象调用COM组件一样调用.NET对象，使.NET程序
象使用.NET对象一样使用COM组件，微软在处理方式上采用了Adapter模式，对COM对象进行包装，这个包装类就是RCW(Runtime Callable Wrapper)。RCW实际上是runtime生成的一个.NET类，它包装了COM组件的方法，并内部实现对COM组件的调用。如下图所示：
图7 .NET程序与COM互相调用示意图