李建忠设计模式之“接口隔离”模式

最新推荐文章于 2024-05-14 16:31:40 发布

chunis

最新推荐文章于 2024-05-14 16:31:40 发布

阅读量190

点赞数

分类专栏：李建忠设计模式笔记文章标签：设计模式 c++

本文链接：https://blog.csdn.net/Godlichangwu/article/details/127002417

版权

李建忠设计模式笔记专栏收录该内容

11 篇文章 1 订阅

订阅专栏

在组件构建过程中，某些接口之间直接的常常会带来很多问题、甚至根本无法实现。采用添加一层间接（稳定）接口，来隔离本来互相紧密关联的接口是一种常见的解决方案。

典型模式：Facade、Proxy、Adapter、 Mediator

门面模式（Facade）

定义

Facade为子系统中的一组接口提供一个一致（稳定）的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用（复用）。

——《设计模式》GoF

动机

上述A方案的问题在于组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战。
如何简化外部客户程序和系统间的交互接口？如何将外部客户程序的演化和内部子系统的变化之间的依赖相互解耦?

结构图

门面模式结构图

要点

从客户程序的角度来看，Facade模式简化了整个组件系统的接口，对于组件内部与外部客户程序来说，达到了一种“解耦”的效果——内部子系统的任何变化不会影响到Facade接口的变化。
Facade设计模式更注重从架构的层次去看整个系统，而不是单个
类的层次。Facade很多时候更是一种架构设计模式。
Facade设计模式并非一个集装箱，可以任意地放进任何多个对象。Facade模式中组件的内部应该是“相互耦合关系比较大的一系列组件”，而不是一个简单的功能集合。

总结

个人感觉Facade模式就是一种将某一类相互关联或者说功能同类的对象封装起来并向外部提供统一的接口的思想，例如web开发中的分层（DAO、Service、Controller）。

代理模式（Proxy）

定义

为其他对象提供一种代理以控制（隔离，使用接口）对这个对象的访问。

——《设计模式》GoF

动机

在面向对象系统中，有些对象由于某种原因（比如对象创建的开消很大，或者某些操作需要安全控制，或者需要进程外的访问等），直接访问会给使用者、或者系统结构带来很多麻烦。
如何在不失去透明操作（不失去一致性，还像之前操作一样）对象的同时来管理/控制这些对象特有的复杂性？增加一层间接层是软件开发中常见的解决方式。

结构图

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qnp7aXrF-1663862413452)(http://qny.cwnest.top/designPattern/屏幕截图.png)]

代码

class Isubject{
public:
    virtual void process();
};

class RealSubject: public Isubject{
public:
    virtual void process(){
        //...
    }
};
//Proxy的设计常常非常复杂
class SubjectProxy: public Isubject{
public:
    virtual void process(){
        //实现一种对RealSubject的间接访问
        //不同情况实现的方法相差非常大，但这种代理的总体思想是一致的
        //...
    }
};

// 由于性能、分布式或者其他某种原因ClientApp不能直接使用RealSubject对象，
// 可以使用SubjectProxy实现对RealSubject对象的一种透明化的操作
class ClientApp{
    ISubject* subject;
public:
    ClientApp(){
        subject = SubjectFactory.createProxy();//subject = new SubjectProxy();
        //...
    }
    void doTask(){
        //...
        subject->process();
        //...
    }
};

要点

“增加一层间接层”是软件系统中对许多复杂问题的一种常见解决方法。在面向对象系统中，直接使用某些对象会带来很多问题，作为间接层的proxy对象便是解决这一问题的常用手段。
具体proxy设计模式的实现方法、实现粒度都相差很大，有些可能对单个对象做细粒度的控制，如copy-on-write技术，有些可能对组件模块提供抽象代理层,在架构层次对对象做proxy。
Proxy并不一定要求保持接口完整的一致性，只要够实现间接控制，有时候损及一些透明性是可以接受的。

总结

简单来说，代理模式就是在调用者由于某种原因无法直接调用目标对象的时候，可以利用一个能够为调用者对目标对象进行操作的代理类完成操作，这样的代理操作常常会比较复杂或者能够获得一定的好处（例如提升性能等）。

适配器模式（Adapter）

定义

将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

——《设计模式》GoF

动机

在软件系统中，由于应用环境的变化，常常需要将“一些现存的对象"放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。
如何应对这种“迁移的变化”?如何既能利用现有对象的良好实现，同时又能满足新的应用环境所要求的接口？

结构图

适配器模式结构图

代码

// 由于某种原因需要进行接口适配，两个接口之间存在功能上的可复用性和关联性并且可以适配
// 目标接口（新接口）
class ITarget{
public：
    virtual void process() = 0;
};

//待转换接口（老接口）
class IAdaptee{
    virtual void foo(int data) = 0;
    virtual int bar() = 0;
};
class OldClass():public IAdapter{
    //...
};
//适配器
class Adapter: public ITarget{
protected:    
    IAdaptee* pAdaptee;
public:
    Adapter(IAdaptee* pAdaptee){
        this->pAdaptee = pAdaptee
    }
    virtual void process(){
        //用伪码表示转换过程
        int data = pAdaptee->bar();
        pAdaptee->foo(data);
        //...
    }
};
int main(){
    IAdaptee pAdaptee = new OldClass();
    ITarget* pTarget = new Adapter(pAdaptee);
    pTarget->process();
}

要点

Adapter模式主要应用于“希望复用一些现存的类，但是接口又与复用环境要求不一致的情况”，在遗留代码复用、类库迁移等方面非常有用。
GoF 23 定义了两种Adapter模式的实现结构：对象适配器和类适配器。但类适配器采用“多继承”的实现方式，一般不推荐使用(几乎不用，很多语言也不支持）。对象适配器采用“对象组合”的方式，更符合松耦合精神。
Adapter模式可以实现的非常灵活，不必拘泥于Gof23中定义的两种结构。例如，完全可以将Adapter模式中的“现存对象”作为新的接口方法参数，来达到适配的目的。

总结

Adapter模式巧妙的利用继承和组合两种方式完成一个类向另一个类转换的过程，使得两个本来接口不一致的类可以通过一个中间的适配器类拥有同样的接口。适配器模式和我们生活中很多的东西思想一致，例如充电头转换器等。

中介者模式（Mediator）

定义

用一个中介对象来封装**（封装变化）一系列的对象交互。中介者使各对象不需要显式的相互引用**(编译时依赖→运行时依赖)，从而使其耦合松散（管理变化），而且可以独立地改变它们之间的交互。

——《设计模式》GoF

动机

在软件构建过程中，经常会出现多个对象关联交互的情况，对象之间常常会维持一种复杂的引用关系，如果遇到一些需求的更改，这种直接的引用关系将面临不断的变化。
在这种情况下，我们可使用一个“中介对象”来管理对象间的关联关系，避免相互交互的对象之间的紧耦合引用关系，从而更好地抵御变化。

结构图

Colleage对象依赖Mediator，继承Mediator的ConcreteMediator又同时依赖ConcreteColleage1和ConcreteColleage2，通过这种双向绑定的方式使得ConcreteColleage1和ConcreteColleage2不会产生直接依赖。但实际实现给多的是下面的方式，通过一个和1_{5对象进行双向绑定的中介者对象从而使得1}5对象相互之间不再相互依赖。

要点

将多个对象间复杂的关联关系解耦，Mediator模式将多个对象间的控制逻辑进行集中管理，变“多个对象互相关联”为“多个对象和一个中介者关联”，简化了系统的维护，抵御了可能的变化。
随着控制逻辑的复杂化，Mediator具体对象的实现可能相当复杂。这时候可以对Mediator对象进行分解处理。
Facade模式是解耦系统间（单向）的对象关联关系；Mediator模式是解耦系统内各个对象之间（双向）的关联关系。

总结

和Facade模式类似，都是提供一种隔离机制，但是facade模式提供的是系统内部和外部成员之间的隔离，而Mediator模式通常提供的是系统内部成员之间的复杂依赖关系的隔离。

chunis

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
李建忠设计模式之“接口隔离”模式

在组件构建过程中，某些接口之间直接的常常会带来很多问题、甚至根本无法实现。采用添加一层间接（稳定）接口，来隔离本来互相紧密关联的接口是一种常见的解决方案。典型模式：Facade、Proxy、Adapter、 Mediator
复制链接

扫一扫