1、定义

1.1 标准定义

门面模式（Facade Pattern）也叫做外观模式，是一种比较常用的封装模式，其定义如下：
Provide a unified interface to a set of interfaces in a subsystem.Facade defines a higher-level interface that makes the subsystem easier to use.（要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。）

1.2 通用类图

门面模式注重“统一的对象”，也就是提供一个访问子系统的接口，除了这个接口不允许有任何访问子系统的行为发生 。

类图就这么简单，但是它代表的意义可是异常复杂，Subsystem Classes是子系统所有类的简称，它可能代表一个类，也可能代表几十个对象的集合。甭管多少对象，我们把这些对象全部圈入子系统的范畴。

门面对象是外界访问子系统内部的唯一通道，不管子系统内部是多么杂乱无章，只要有门面对象在，就可以做到“金玉其外，败絮其中”。

● Facade门面角色
客户端可以调用这个角色的方法。此角色知晓子系统的所有功能和责任。一般情况下，本角色会将所有从客户端发来的请求委派到相应的子系统去， 也就说该角色没有实际的业务逻辑，只是一个委托类。
● subsystem子系统角色
可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类，而是一个类的集合。子系统并不知道门面的存在。对于子系统而言，门面仅仅是另外一个客户端而已。

2、实现

2.1 类图

SubSystem（子系统） 负责处理复杂的逻辑处理。不直接跟客户打交道。
Facade（门面） 负责跟子系统进行交互，提供简单易用的功能或接口给客户。
Client（客户） 通过门面和子系统进行交互，不需关心子系统的细节。

 2.2 实现

门面模式的代码很简单，类图也几乎和通用类图相同，只是在日常运用中，需要根据项目做一些调整和扩展。

#include <iostream>

using namespace std;

class SubsystemA
{
public:
    SubsystemA(){};
    ~SubsystemA(){};
    void dosomething()
    {
        cout<< "A dosomething" <<endl;
    }

};

class SubsystemB
{
public:
    SubsystemB(){};
    ~SubsystemB(){};
    void dosomething()
    {
        cout<< "B dosomething" <<endl;
    }

};

class SubsystemC
{
public:
    SubsystemC(){};
    ~SubsystemC(){};
    void dosomething()
    {
        cout<< "C dosomething" <<endl;
    }

};

class Facade
{
public:
    Facade(){};
    ~Facade(){};
    void dosomething()
    {
        m_sub_a.dosomething();
        m_sub_b.dosomething();
        m_sub_c.dosomething();
    }
private:
    SubsystemA m_sub_a;
    SubsystemB m_sub_b;
    SubsystemC m_sub_c;
};

int main(void)
{    
    Facade *f = new Facade();
    f->dosomething();

    delete f;
    return 0;
}
 

3、总结

3.1 优点

● 减少系统的相互依赖
想想看，如果我们不使用门面模式，外界访问直接深入到子系统内部，相互之间是一种强耦合关系，你死我就死，你活我才能活，这样的强依赖是系统设计所不能接受的，门面模式的出现就很好地解决了该问题，所有的依赖都是对门面对象的依赖，与子系统无关。
● 提高了灵活性
依赖减少了，灵活性自然提高了。不管子系统内部如何变化，只要不影响到门面对象，任你自由活动。
● 提高安全性
想让你访问子系统的哪些业务就开通哪些逻辑，不在门面上开通的方法，你休想访问到 。

 3.2 缺点

门面模式最大的缺点就是不符合开闭原则，对修改关闭，对扩展开放，看看我们那个门面对象吧，它可是重中之重，一旦在系统投产后发现有一个小错误，你怎么解决？完全遵从开闭原则，根本没办法解决。继承？覆写？都顶不上用，唯一能做的一件事就是修改门面角色的代码，这个风险相当大，这就需要大家在设计的时候慎之又慎，多思考几遍才会有好收获。

3.3 使用场景

● 为一个复杂的模块或子系统提供一个供外界访问的接口
● 子系统相对独立——外界对子系统的访问只要黑箱操作即可
比如利息的计算问题， 没有深厚的业务知识和扎实的技术水平是不可能开发出该子系统的，但是对于使用该系统的开发人员来说，他需要做的就是输入金额以及存期，其他的都不用关心，返回的结果就是利息，这时候，门面模式是非使用不可了。
● 预防低水平人员带来的风险扩散
比如一个低水平的技术人员参与项目开发， 为降低个人代码质量对整体项目的影响风险，一般的做法是“画地为牢”，只能在指定的子系统中开发，然后再提供门面接口进行访问操作。

3.4 注意事项

3.4.1  一个子系统可以有多个门面

● 门面已经庞大到不能忍受的程度 

● 子系统可以提供不同访问路径

3.4.2 门面不参与子系统内的业务逻辑

门面对象只是提供一个访问子系统的一个路径而已，它不应该也不能参与具体的业务逻辑，否则就会产生一个倒依赖的问题：子系统必须依赖门面才能被访问，这是设计上一个严重错误，不仅违反了单一职责原则，同时也破坏了系统的封装性。

门面角色应该是稳定，它不应该经常变化，一个系统一旦投入运行它就不应该被改变，它是一个系统对外的接口。业务逻辑是会经常变化的，我们已经把它的变化封装在子系统内部，无论你如何变化，对外界的访问者来说，都还是同一个门面，同样的方法——这才是架构师最希望看到的结构。

【设计模式】 门面模式