外观模式

一 应用场景
一个人自己泡茶的话需要准备茶叶、茶具、开水，然后泡茶，但是如果去茶馆喝茶的话直接告诉服务员喝什么茶就好了，服务员就像是一个外观角色，处理了很多事情，展现给客人的是一个接口。
二 定义
外观模式 facade pattern：外部与一个子系统的通信通过一个统一的外观角色进行。为子系统中的一组接口提供一个一致的入口，外观模式定义了一个高层接口，这个接口使这个子系统更加容易使用。
如果没有外观角色，客户端可能需要和很多的子系统交互，系统很大的耦合性。但是系统增加外观角色后就可以直接和外观角色直接交互，降低系统的耦合度。

三 C++实现一个外观类
Cup.h

#pragma once 

#include <iostream>
#include <string>
using namespace std;

class Cup
{
public:
    Cup(){}

    virtual ~Cup(){}

    void getCup()
    {
        std::cout << "get a cup" << std::endl;
    }
};

Tea.h

#pragma once 

#include <iostream>
#include <string>
using namespace std;

class Tea
{
public:
    Tea(){}
    virtual ~Tea(){};

    void getTea()
    {
        std::cout << "put tea" << std::endl;
    }
};

Water.h

#pragma once 

#include <iostream>
#include <string>
using namespace std;

class Water
{
public:
    Water(){}

    virtual ~Water(){}

    void pourWater()
    {
        std::cout << "pour water into cup" << std::endl;
    }
};

FacadeDrinkTea.h

#pragma once
#include "Cup.h"
#include "Tea.h"
#include "Water.h"


class FacadeDrinkTea
{
private:
    Cup * cup;
    Tea * tea;
    Water * water ;

public:
    FacadeDrinkTea(){
        cup = new Cup();
        tea = new Tea();
        water = new Water();
    }

    virtual ~FacadeDrinkTea(){
        delete cup;
        cup = NULL;
        delete tea;
        tea = NULL;
        delete water;
        water = NULL;
    }

    void drinkTea(){
        std::cout << "someone drinks tea" << std::endl;
        cup->getCup();
        tea->getTea();
        water->pourWater();
    }
};

main.cpp

#include <iostream>
#include <string>
#include "FacadeDrinkTea.h"

int main()
{
    FacadeDrinkTea * f_drink_tea = new FacadeDrinkTea();
    f_drink_tea->drinkTea();
    delete f_drink_tea;
    f_drink_tea = NULL;
    system("pause");
    return 0;
}

运行结果：

每次喝茶的时候只和FacadeDrinkTea打交道就可以了。

四总结
优点：
1 对客户屏蔽子系统组件，客户代码将变得很简单，与之关联的对象也很少。
2 实现了子系统与客户之间的松耦合关系，这使得子系统的组件变化不会影响到调用它的客户类，只需要调整外观类即可。
3 只是提供了一个访问子系统的统一入口，并不影响用户直接使用子系统类。

缺点
1 不能很好地限制客户使用子系统类，如果对客户访问子系统类做太多的限制则减少了可变性和灵活性。
2 在不引入抽象外观类的情况下，增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。