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

门面模式（Facade）

错误示例：应用1，可能需要用到子系统中的多模块功能，应用2，也可能用到多个模块功能，这些，如果直接开放模块接口，让应用直接调用模块，会产生很多紧密且复杂的耦合。

这个时候可以为子系统中的一组模块（接口）提供一致（稳定）的界面，使得整个子系统更加容易使用，并且屏蔽了内部子系统中可能存在的变化。

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

代理模式（proxy）

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

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

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

class SpecificInterface : public Interface{
public:
    virtual void process(){
        // ...
    }
};

class ClientApp{
    Interface *interPtr;
public:
    ClientApp(){
        interPtr = new SpecificInterface(); // 但在某些情况下，可能不能直接得到这个对象，并用来操作，比如它其实可能是存在另一个机器上的功能
    }

    void DoTask(){
        //
        interPtr->process();
        //
    }
};

// 因此可能需要定义一个代理
class SpecificProxy : public Interface{
public:
    virtual void process(){
        // ...
        // 实现对SpecificInterface的间接访问，可能会很复杂，比如可能会用到网络通信和其他主机联系
        // ...
    }
};


class ClientApp{
    Interface *interPtr;
public:
    ClientApp(){
        interPtr = new SpecificProxy(); // 这个SpecificProxy能在本机下正常访问
    }

    void DoTask(){
        //
        interPtr->process();
        //
    }
};

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

适配器（Adapter）

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

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

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

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

// 遗留类型
class OldClass: public IAdaptee{
public:

};

// 适配器
class Adapter : public ITarget{
protected:
    IAdaptee *pAdap; // 老接口的指针（组合形式）
public:
    Adapter(IAdaptee * p){
        pAdap = p;
    }

    virtual void process(){
        // 利用老接口操作
        int data = pAdap->bar();
        pAdap->foo(data);
    }
};

int main(){
    IAdaptee *pAdap = new OldClass();

    ITarget *pTarget = new Adapter(pAdap);
    pTarget->process();
}

• 总的来说就是定义一个继承自新接口的类，然后使用组合的方式，调用老接口的方法
• STL标准库里的stack和queue就用到类似的思想，其实现会使用deque对象来操作，但提供了不一样的接口。

要点总结：
– Adapter模式主要应用于“希望复用一些现存的类，但是接口又与复用环境要求不一致的情况”，在遗留代码复用、类库迁移等方面非常有用。
– GoF23定义了两种Adapter模式的实现结构：对象适配器（组合的形式实现，如上例）和类适配器（多继承的形式实现，不推荐）。
– Adapter模式实现起来可以非常灵活，不必拘泥于GoF23中定义的两种结构。例如，完全可以将Adapter模式中的“现存对象”作为新接口方法参数，来达到适配的目的。

中介者模式（Mediator）

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

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

原先对象和对象之间是相互依赖的（id01-id05）

但可以通过设置一个中介对象来，对象和中介对象相互依赖，从而避免对象和对象之间的直接依赖。

要点总结：
– 将多个对象间复杂的关联关系解耦，Mediator模式将多个对象间的控制逻辑进行集中管理，变“多个对象互相关联”为“多个对象和一个中介者关联”，简化了系统的维护，抵御了可能的变化。
– 随着控制逻辑的复杂化，Mediator具体对象的实现可能相当复杂，这时候可以对Mediator对象进行分解处理。

接口隔离模式总结：
Facade（门面模式）是解耦系统间（单向）的对象关联关系
Proxy（代理模式）解决的是两对象之间，本来可以直接依赖，但是由于某种特殊原因（性能、安全、分布式等原因），必须隔离，从A访问B变成A去访问B的代理，由B的代理再去解决这些安全、性能、分布式的问题就，最终完成对B的调用
Adapter解决的是老接口和新接口之间不匹配的问题，这个时候需要基于老接口建立一个适配器（组合的形式），继承新接口，并实现其功能。
Mediator模式是解耦系统内各个对象之间（双向）的关联关系。