.Net结构型设计模式之适配器模式(Adapter)

一、动机(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)的文章就介绍到这了。希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • .Net结构型设计模式之适配器模式(Adapter)

    一.动机(Motivation) 在软件系统中,由于应用环境的变化,常常需要将“一些现存的对象”放在新的环境中应用,但是新环境要求的接口是这些现存对象所不满足的. 如何应对这种“迁移的变化”?如何既能利用现有对象的良好实现,同时又能满足新的应用环境所要求的接口? 二.意图(Intent) 将一个类的接口转换成客户希望的另一个接口.Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作. 例说Adapter应用 这种实际上是一种委派的调用,本来是发送请求给MyStack,但是M

  • Java结构型设计模式之适配器模式详解

    目录 适配器模式 分类 应用场景 优缺点 主要角色 类适配器 创建目标角色(Target) 创建源角色(Adaptee) 创建适配器(Adapter) 客户端调用 对象适配器 创建目标角色(Target) 创建源角色(Adaptee) 创建适配器(Adapter) 客户端调用 接口适配器 创建目标角色(Target) 创建源角色(Adaptee) 创建适配器(Adapter) 客户端调用 适配器模式 适配器模式(Adapter Pattern)又叫做变压器模式,属于结构型设计模式. 它的功能是将

  • .Net结构型设计模式之桥接模式(Bridge)

    一.动机(Motivation) 在很多游戏场景中,会有这样的情况:[装备]本身会有的自己固有的逻辑,比如枪支,会有型号的问题,同时现在很多的游戏又在不同的介质平台上运行和使用,这样就使得游戏的[装备]具有了两个变化的维度——一个变化的维度为“平台的变化”,另一个变化的维度为“型号的变化”.如果我们要写代码实现这款游戏,难道我们针对每种平台都实现一套独立的[装备]吗?复用在哪里?如何应对这种“多维度的变化”?如何利用面向对象技术来使得[装备]可以轻松地沿着“平台”和“型号”两个方向变化,而不引入

  • .Net结构型设计模式之代理模式(Proxy)

    目录 一.动机(Motivate) 二.意图(Intent) 三.结构图(Structure) 四.模式的组成 五.代理模式的分类: 六.代理模式的具体实现 七.代理模式的实现要点: 1.代理模式的优点: 2.代理模式的缺点: 3.代理模式的使用场景: 八..NET 中代理模式的实现 九.总结 一.动机(Motivate) 在面向对象系统中,有些对象由于某种原因(比如对象创建的开销很大,或者某些操作需要安全控制,或者需要进程外的访问等),直接访问会给使用者.或者系统结构带来很多麻烦.如何在不失去

  • .Net结构型设计模式之组合模式(Composite)

    目录 一.动机(Motivate) 二.意图(Intent) 三.结构图(Structure) 四.模式的组成 五.组合模式的具体代码实现 1.透明式的组合模式 2.安全式的组合模式 六.组合模式的实现要点: 组合模式的优点: 组合模式的缺点: 在以下情况下应该考虑使用组合模式: 七..NET 中组合模式的实现 一.动机(Motivate) 在我们的操作系统中有文件夹的概念,文件夹可以包含文件夹,可以嵌套多层,最里面包含的是文件,这个概念和“俄罗斯套娃”很像.当然还有很多的例子,例如我们使用系统

  • .Net结构型设计模式之装饰模式(Decorator)

    目录 一.动机(Motivate) 二.意图(Intent) 三.结构图(Structure) 四.模式的组成 五 .装饰模式的具体代码实现 六.装饰模式的实现要点: 1.装饰模式的优点: 2.装饰模式的缺点: 3.在以下情况下应当使用桥接模式: 七..NET 中装饰模式的实现 一.动机(Motivate) 在房子装修的过程中,各种功能可以相互组合,来增加房子的功用.类似的,如果我们在软件系统中,要给某个类型或者对象增加功能,如果使用“继承”的方案来写代码,就会出现子类暴涨的情况.比如:IMar

  • .Net结构型设计模式之享元模式(Flyweight)

    目录 一.动机(Motivate) 二.意图(Intent) 三.结构图(Structure) 四.模式的组成 五.享元模式的具体代码实现 六.享元模式的实现要点: 1.享元模式的优点 2.享元模式的缺点 3.在下面所有条件都满足时,可以考虑使用享元模式: 七..NET 中享元模式的实现 一.动机(Motivate) 在软件系统中,采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中,从而带来很高的运行时代价——主要指内存需求方面的代价.如何在避免大量细粒度对象问题的同时,让外部客户程序

  • .Net结构型设计模式之外观模式(Facade)

    目录 一.动机(Motivate) 二.意图(Intent) 三.结构图(Structure) 四.模式的组成 五.外观模式的具体实现 六.实现要点: 1.外观模式的优点: 2.外观模式的缺点: 3.在以下情况下可以考虑使用外观模式: 七.NET 中外观模式的实现 一.动机(Motivate) 在软件系统开发的过程中,当组件的客户(即外部接口,或客户程序)和组件中各种复杂的子系统有了过多的耦合,随着外部客户程序和各子系统的演化,这种过多的耦合面临很多变化的挑战.如何简化外部客户程序和系统间的交互

  • Java结构型设计模式之享元模式示例详解

    目录 享元模式 概述 目的 应用场景 优缺点 主要角色 享元模式结构 内部状态和外部状态 享元模式的基本使用 创建抽象享元角色 创建具体享元角色 创建享元工厂 客户端调用 总结 享元模式实现数据库连接池 创建数据库连接池 使用数据库连接池 享元模式 概述 享元模式(Flyweight Pattern)又称为轻量级模式,是对象池的一种实现.属于结构型模式. 类似于线程池,线程池可以避免不停的创建和销毁多个对象,消耗性能.享元模式提供了减少对象数量从而改善应用所需的对象结构的方式. 享元模式尝试重用

  • Java结构型设计模式中代理模式示例详解

    目录 代理模式 分类 主要角色 作用 静态代理与动态代理的区别 静态代理的基本使用 创建抽象主题 创建真实主题 创建代理主题 客户端调用 JDK动态代理的基本使用 创建抽象主题 创建真实主题 创建代理主题 客户端调用 小优化 CGLIB动态代理的基本使用 创建抽象主题 创建真实主题 创建代理主题 客户端调用 小优化 CGLIB与JDK动态代理区别 1.执行条件 2.实现机制 3.性能 代理模式 代理模式(Proxy Pattern)属于结构型模式. 它是指为其他对象提供一种代理以控制对这个对象的

随机推荐