设计模式之“接口隔离“模式：Façade、Proxy、Adapter、Mediator

---

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

---

---

1. Façade 门面模式

---

1.1 Façade 门面模式动机

系统间耦合的复杂度：

客户端依赖于子系统所提供的接口，是单向依赖关系。

上述A方案的问题在于组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战。

那么如何简化外部客户程序和系统间的交互接口？如何将外部客户程序的演化和内部子系统的变化之间的依赖相互解耦？

---

1.2 模式定义

为子系统中的一组接口提供一个一致(稳定)的界面，Façade 门面模式定义了一个高层接口，这个接口使得这一子系统更加容易使用(复用)。

这种思想在计算机体系中很广泛，比如软硬件之间的操作系统，人类和硬件之间的软件，都可以视作 Façade 门面模式的应用。

---

1.3 要点总结

• 从客户程序的角度看，Façade 门面模式简化了整个组件系统的接口，对于组件内部与外部客户程序来说，达到了一种"解耦"的效果——内部子系统的任何变化不会影响到 Façade 接口的变化(即对内可调整，对外保持不变)；
• Façade 设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Façade 模式很多时候更是一种架构设计模式；
• Façade 模式并非一个可放入任何多对象的集装箱。Façade 组件的内部应当是"相互耦合关系比较大的一系列组件"，而不是一简单功能集合；

---

---

2. Proxy 代理模式

---

2.1 Proxy 代理模式动机

在面向对象系统中，有些对象由于某种原因(比如对象创建的开销很大，或者某些操作需要安全控制，或者需要进程外的访问等)，直接访问会给使用者、或者系统结构带来很多麻烦。

那么如何在不失去透明操作对象的同时来管理/控制这些对象特有的复杂性？

增加一层间接层（代理层）是软件开发中常见的解决方式，特别是在分布式系统中有着广泛且重要的应用。

---

2.2 模式定义

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

---

2.3 实例代码

实例代码中 ISubject 中的 字母I 代表 接口Interface 之意。SubjectProxy 直接继承自 ISubject,客户工厂实例化 ISubject时，使用 SubjectProxy 而不再使用 RealSubject。这样就能够在不失透明性的条件下，完成对 RealSubject 相关内容的访问。

SubjectProxy.cpp

RealSubject.cpp

---

2.4 要点总结

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

---

---

3. Adapter 适配器模式

---

3.1 Adapter 适配器模式动机

在软件系统中，由于应用环境的变化，常常需要将"一些现存的对象"放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。

那么如何应对这种"迁移的变化"？如何既能利用现有对象的良好实现，同时又能满足新的应用环境所要求的接口？

类似生活当中的usb适配器，笔电只有type-c接口而没有usb-a的接口了，那么接上一个接口适配器就可以继续使用usb-a接口的设备了。

---

3.2 模式定义

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

STL中的适配器的概念就是这样的，三种适配器：容器适配器、迭代器适配器和函数适配器都是采用这样的理念(对应类型是对象适配器，has-a)，详见：STL适配器详解

---

3.3 实例代码

//目标接口（新接口）
class ITarget{
public:
    virtual void process()=0;
};

//遗留接口（老接口）
class IAdaptee{
public:
    virtual void foo(int data)=0;
    virtual int bar()=0;
};

//遗留类型
class OldClass: public IAdaptee{
    //....
};

//对象适配器
class Adapter: public ITarget{ //继承
protected:
    IAdaptee* pAdaptee;//组合    
public:    
    Adapter(IAdaptee* pAdaptee){
        this->pAdaptee=pAdaptee;
    }    
    virtual void process(){
        int data=pAdaptee->bar();
        pAdaptee->foo(data);   
    }
};


//类适配器
class Adapter: public ITarget,
               protected OldClass { //多继承
                          
}


int main(){
    IAdaptee* pAdaptee=new OldClass();    
    ITarget* pTarget=new Adapter(pAdaptee);
    pTarget->process();  
}


//STL的容器适配器，queue和stack都是内含一个deque实现的
//均是对象适配器
class stack{
    deqeue container;
    
};

class queue{
    deqeue container;
    
};

---

3.4 要点总结

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

---

---

4. Mediator 中介者模式

---

4.1 Mediator 中介者模式动机

在软件构建过程中，经常会出现多个对象互相关联交互的情况，对象之间常常会维持一种复杂的引用关系，如果遇到一些需求的更改，这种直接的引用关系将面临不断地变化。

在这种情况下，可使用一个 Mediator对象 来管理对象间的关联关系，避免相互的对象之间的紧耦合引用关系，从而更好地抵御变化。

---

4.2 模式定义

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

---

4.3 要点总结

• 将多个对象间复杂的关联关系解耦，Mediator 模式将多个对象间的逻辑控制进行集中管理，变 多个对象互相关联 为 多个对象和一个中介者关联 ，简化了系统的维护，抵御了可能的变化；
• 随着控制逻辑的复杂化，Mediator 具体对象的实现可能相当复杂。这时候可对 Mediator对象 进行分解处理；
• Façade 模式是解耦 系统间 (单向)的对象关联关系，应用场景是内部系统和外部系统之间的连接，以保持稳定性；
• Mediator 模式是解耦 系统内 各个对象之间(双向)的关联关系，应用场景是系统内发生了多个对象互相关联交互情况，DIP原则在多个对象场景冲的扩展形式；