C++设计模式——外观模式(Facade Pattern)

C++设计模式——外观模式(Facade Pattern)

微信公众号：幼儿园的学霸

目录

前言

不得不说，外观模式在开发过程中运用频率非常高，尤其现在各种第三方SDK“充斥”在我们的开发中，这些SDK大多会使用外观模式。通过一个外观类使的整个系统的接口只有一个统一的高层接口，这样能够降低用户的使用成本，也能够对用户屏蔽很多实现细节。外观模式也是我们封装API的常用手段，例如网络模块、python的调包等。还有我们平时使用的ide，ide就是外观类，客户端也就是开发人员通过debug按钮调用其debug子系统等等。如果查看一些源码，如opencv就会发现，外观模式出现的频率是多么的高，像常用的HOG、SVM、VideoWriter 中都有外观模式的应用。

定义

定义与特点

Facade Pattern provides a unified interface to a set of interfaces in subsystems. Facade defines a higher-level interface that makes the subsystem easier to use.

外观（Facade）模式的定义：是一种通过为多个复杂的子系统提供一个一致的接口，而使这些子系统更加容易被访问的模式。该模式对外有一个统一接口，外部应用程序不用关心内部子系统的具体的细节，这样会大大降低应用程序的复杂度，提高了程序的可维护性。

这种类型的设计模式属于结构型模式，它向现有的系统添加一个接口，来隐藏系统的复杂性，隐藏的同时，提供一个可供客户端访问系统的接口。

这种模式涉及到一个单一的类，该类提供了客户端请求的简化方法和对现有系统类方法的委托调用。

简化+委托调用

或者说，外观模式是用来简化接口的。
通常，我们觉得一个子系统不好用，可能是因为它提供的外部接口太接近底层组件，让我们用起来感到很麻烦。因为我们不需要知道内部细节，我们只想要一个“一键完成”功能，调用子系统的某个方法，它可能替我们完成了图片预处理，而不是靠我们自己来调用灰度化方法、图像增强算法、噪声处理方法等等来一步步实现预处理。
如果子系统提供的接口太接近底层组件，不仅不易用，而且破坏了子系统的封装（想调用子系统就必须了解其各个底层组件，我们被迫知道了太多不应该知道的细节）

结构

外观（Facade）模式包含以下主要角色:

• 外观（Facade）角色：为多个子系统对外提供一个共同的接口。
• 子系统（Sub System）角色：实现系统的部分功能，客户可以通过外观角色访问它。
• 客户（Client）角色：通过一个外观角色访问各个子系统的功能。

其结构图如下图所示：

代码示例

关键代码: 在客户端和复杂系统之间再加一层，这一层将调用顺序、依赖关系等处理好。

/*
* 关键代码：客户与系统之间加一个外观层，外观层处理系统的调用关系、依赖关系等。
*以下实例以电脑的启动过程为例，客户端只关心电脑开机的、关机的过程，并不需要了解电脑内部子系统的启动过程。
*/

//抽象控件类，提供接口
class Control {
public:
    virtual ~Control() = default;//建议将基类的析构函数定义为虚函数
    virtual void start() = 0;

    virtual void shutdown() = 0;
};

//子控件， 主机
class Host : public Control {
public:
    void start() override {
        std::cout << "Host start" << std::endl;;
    }

    void shutdown() override {
        std::cout << "Host shutdown" << std::endl;;;
    }
};

//子控件， 显示屏
class LCDDisplay : public Control {
public:
    void start() override {
        std::cout << "LCD Display start" << std::endl;;
    }

    void shutdown() override {
        std::cout << "LCD Display shutdonw" << std::endl;;
    }
};

//子控件， 外部设备
class Peripheral : public Control {
public:
    void start() override {
        std::cout << "Peripheral start" << std::endl;;
    }

    void shutdown() override {
        std::cout << "Peripheral shutdown" << std::endl;;
    }
};

class Computer {
public:
    void start() {
        m_host.start();
        m_display.start();
        m_pPeripheral->start();
        std::cout << "Computer start" << std::endl;;
    }

    void shutdown() {
        m_host.shutdown();
        m_display.shutdown();
        m_pPeripheral->shutdown();
        std::cout << "Computer shutdown" << std::endl;;
    }

private:
    //私有，屏蔽子系统
    Host m_host;
    LCDDisplay m_display;
    std::shared_ptr m_pPeripheral=std::make_shared();
};

int main() {
    Computer computer;
    computer.start();

    std::cout << "=====Client do something else !====" << std::endl;;

    computer.shutdown();
    return 0;
    //运行结果:
    //Host start
    //LCD Display start
    //Peripheral start
    //Computer start
    //=====Client do something else !====
    //Host shutdown
    //LCD Display shutdonw
    //Peripheral shutdown
    //Computer shutdown
}

总结

相关设计模式

外观模式和单例模式：通常可以把外观对象设计成单例模式
外观模式和抽象工厂模式：外观类可以通过抽象工厂获取子系统的实例，子系统可以从内部对外观类进行屏蔽

外观模式和中介模式：外观模式关注的是外界与子系统间的交互，而中介者模式关注的是子系统内部间的交互.中介模式尚未研究到，暂时不深入。TODO

优缺点

外观模式是迪米特法则的典型应用

迪米特法则，即最少知道原则

• 优点
  1.降低了子系统与客户端之间的耦合，减少了系统的相互依赖，使得子系统的变化不会影响调用它的客户类。
  2.提高了灵活性。不管系统内部如何变化，只要不影响到外观对象，任你自由活动
  3.提高了安全性。想让你访问子系统的哪些业务就开通哪些逻辑，不在外观上开通的方法，你就访问不到.
• 缺点
  增加新的子系统可能需要修改外观类或客户端的源码，违背了开闭原则

针对外观模式的缺点，可以通过引入抽象外观类在一定程度上解决该问题，客户端针对抽象外观类进行编程。对于新的业务需求，不修改原有外观类，而对应增加一个新的具体外观类，由新的具体外观类来关联新的子系统对象，同时通过修改配置文件来达到不修改源代码并更换外观类的目的。

使用场景

1.为一个复杂的模块或子系统提供一个外界访问的接口
2.子系统相对独立，外界对子系统的访问只要黑箱操作即可
3.预防低水平人员带来的风险扩散

参考资料

1.外观模式（Facade模式）详解
2.设计模式–外观模式（Facade）
3.设计模式之外观模式（Facade Pattern）
4.外观模式
5.C++ 常用设计模式（学习笔记）

---

下面的是我的公众号二维码图片，欢迎关注。