我要评论一、动机（motivation）
在软件系统中，由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。
如何应对这种“迁移的变化”？如何既能利用现有对象的良好实现，同时又能满足新的应用环境所要求的接口？
二、意图（intent）
将一个类的接口转换成客户希望的另一个接口。adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
例说adapter应用
这种实际上是一种委派的调用，本来是发送请求给mystack，但是mystack实际上是委派给list去处理。mystack在这里其实就是adapter（适配对象），list即是adaptee（被适配的对象），而istack就是客户期望的接口。太直接了，没什么可说的。
三、结构（structure）
适配器有两种结构
1、对象适配器（更常用）
对象适配器使用的是对象组合的方案，它的adapter和adaptee的关系是组合关系，即上面例子中mystack和list是组合关系。
oo中优先使用组合模式，组合模式不适用再考虑继承。因为组合模式更加松耦合，而继承是紧耦合的，父类的任何改动都要导致子类的改动。
上面的例子就是对象适配器。
2、类适配器（不推荐使用）
下面的例子是类适配器。
adapter继承了arraylist，也继承了istack接口，它既可以使用arraylist里的方法，也可以使用istack接口里的方法，这样就感觉有点不伦不类。这个类违反了类应该具有单一职责的原则，它既有arraylist的职责，也有istack的职责，因此这种类适配不是很常用，也不推荐使用。
注意：如果一个方法有可能要委托到2个或2个以上的对象，或者2个或2个以上的类需要委托，对于对象适配器，只需要增加几个内部的属性就可以实现适配。
而对于类适配器，因为c#中类只能是单一继承，它不能继承自2个或2个以上的类，所以类适配器这里便无法使用。
四、模式的组成
可以看出，在适配器模式的结构图有以下角色：
（1）、目标角色（target）：定义client使用的与特定领域相关的接口。
（2）、客户角色（client）：与符合target接口的对象协同。
（3）、被适配角色（adaptee)：定义一个已经存在并已经使用的接口，这个接口需要适配。
（4）、适配器角色（adapte) ：适配器模式的核心。它将对被适配adaptee角色已有的接口转换为目标角色target匹配的接口。对adaptee的接口与target接口进行适配。
五、 适配器模式的具体实现
实现一个对栈的操作，有一个istact接口，里面有三个方法push(进栈)、pop(出栈)和gettopitem(取最顶层元素)，这个istact接口将相当于上面的target，想要实现进栈出栈的操作，如果自己去实现数据结构显得比较麻烦，在此可以将net提供的arraylist类拿来一用，arraylist类就是被适配的对象，相当于上面的adaptee。在写一个适配类stactadapter类完成功能就可以了。
/// <summary>
/// 栈的接口
/// </summary>
public interface istack
{
void push(object item);
void pop();
object gettopitem();
}
/// <summary>
/// 对象适配器
/// </summary>
public class stactadapter : istack
{
arraylist list;
/// <summary>
/// 构造函数中实例化arraylist
/// </summary>
public stactadapter()
{
list = new arraylist();
}
/// <summary>
/// 进栈
/// </summary>
/// <param name="item">压入栈的元素</param>
public void push(object item)
{
list.add(item);
}
/// <summary>
/// 出栈
/// </summary>
public void pop()
{
list.removeat(list.count - 1);
}
/// <summary>
/// 取最顶层的元素
/// </summary>
/// <returns></returns>
public object gettopitem()
{
return list[list.count - 1];
}
}
/// <summary>
/// 客户调用
/// </summary>
public class app
{
static void main(string[] args)
{
istack mystack = new stactadapter();
mystack.push("oec2003");
mystack.push("oec2004");
mystack.push("oec2005");
mystack.pop();
console.writeline(mystack.gettopitem());
}
}六、适配器模式的实现要点：
1、adapter模式主要应用于“希望复用一些现存的类，但是接口又与复用环境要求不一致的情况”，在遗留代码复用、类库迁移等方面非常有用。
2、gof23定义了两种adapter模式的实现结构：对象适配器和类适配器。类适配器采用“多继承”的实现方式，在c#语言中，如果被适配角色是类，target的实现只能是接口，因为c#语言只支持接口的多继承的特性。在c#语言中类适配器也很难支持适配多个对象的情况，同时也会带来了不良的高耦合和违反类的职责单一的原则，所以一般不推荐使用。对象适配器采用“对象组合”的方式，更符合松耦合精神，对适配的对象也没限制，可以一个，也可以多个，但是，使得重定义adaptee的行为较困难，这就需要生成adaptee的子类并且使得adapter引用这个子类而不是引用adaptee本身。adapter模式可以实现的非常灵活，不必拘泥于gof23中定义的两种结构。例如，完全可以将adapter模式中的“现存对象”作为新的接口方法参数，来达到适配的目的。
3、adapter模式本身要求我们尽可能地使用“面向接口的编程”风格，这样才能在后期很方便地适配。
适配器模式用来解决现有对象与客户端期待接口不一致的问题，下面详细总结下适配器两种形式的优缺点。
1、类的适配器模式：
优点：
（1）、可以在不修改原有代码的基础上来复用现有类，很好地符合 “开闭原则”
（2）、可以重新定义adaptee(被适配的类)的部分行为，因为在类适配器模式中，adapter是adaptee的子类
（3）、仅仅引入一个对象，并不需要额外的字段来引用adaptee实例（这个即是优点也是缺点）。
缺点：
（1）、用一个具体的adapter类对adaptee和target进行匹配，当如果想要匹配一个类以及所有它的子类时，类的适配器模式就不能胜任了。因为类的适配器模式中没有引入adaptee的实例，光调用this.specificrequest方法并不能去调用它对应子类的specificrequest方法。
（2）、采用了 “多继承”的实现方式，带来了不良的高耦合。
2、对象的适配器模式
优点：
（1）、可以在不修改原有代码的基础上来复用现有类，很好地符合 “开闭原则”（这点是两种实现方式都具有的）
（2）、采用 “对象组合”的方式，更符合松耦合。
缺点：
使得重定义adaptee的行为较困难，这就需要生成adaptee的子类并且使得adapter引用这个子类而不是引用adaptee本身。
3、适配器模式使用的场景：
（1）、系统需要复用现有类，而该类的接口不符合系统的需求
（2）、想要建立一个可重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作。
（3）、对于对象适配器模式，在设计里需要改变多个已有子类的接口，如果使用类的适配器模式，就要针对每一个子类做一个适配器，而这不太实际。
七、.net 中适配器模式的实现
说道适配器模式在net中的实现就很多了，比如：system.io里面的很多类都有适配器的影子，当我们操作文件的时候，其实里面调用了com的接口实现。以下两点也是适配器使用的案例：
1.在.net中复用com对象：
com对象不符合.net对象的接口，使用tlbimp.exe来创建一个runtime callable wrapper（rcw）以使其符合.net对象的接口，com interop就好像是com和.net之间的一座桥梁。
2..net数据访问类（adapter变体）：
各种数据库并没有提供dataset接口，使用dbdataadapter可以将任何个数据库访问/存取适配到一个dataset对象上，dbdataadapter在数据库和dataset之间做了很好的适配。当然还有sqldataadapter类型了，针对微软sqlserver类型的数据库在和dataset之间进行适配。
到此这篇关于.net结构型设计模式之适配器模式（adapter）的文章就介绍到这了。希望对大家的学习有所帮助，也希望大家多多支持代码网。
发表评论