外观模式

外观(Facade)角色：客户端可以调用这个角色的方法。此角色知晓相关的(一个或者多个)子系统的功能和责任。在正常情况下，本角色会将所有从客户端发来的请求委派到相应的子系统去。                                                                                                                                                                            子系统(subsystem)角色：可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类，而是一个类的集合。每一个子系统都可以被客户端直接调用，或者被外观角色调用。子系统并不知道外观的存在，对于子系统而言，外观仅仅是另外一个客户端而已。

 

//子系统角色
class Subsystem1 
{  
public:  
    void funtion () { ....}  
};  
class Subsystem2 
{  
public:  
    void funtion () {.......}  
};  
class Subsystem3 
{  
public:  
    void funtion () {..... }  
};  

//外观角色
class Facade
{  
public:  
    void Run()   
    {  
        Subsystem1 class1;  
        Subsystem2 class2;  
        Subsystem3 class3;  
        class1.funtion ();  
        class2.funtion ();  
        class3.funtion ();  
    }  
};  

//client
int main()  
{  
    Facade Facadeclass;  
    Facadeclass.Run();  
    return 0;  
}  

适用性

1．为一个复杂子系统提供一个简单接口。2．提高子系统的独立性。3．在层次化结构中，可以使用Facade模式定义系统中每一层的入口。

 

优点

1. 松散耦合：客户端与子系统的耦合松。2. 更好的划分访问层次：方便客户端使用，也很好的隐藏了内部的细节。客户只知道外观角色

缺点        

1.过多的或者是不太合理的Facade也容易让人迷惑，到底是调用Facade好呢，还是直接调用模块好。

 

个人觉得：

一开始这个就想到了建造者模式哟。build模式把也会把一系列过程封装到director的一个函数中。

不同在于：

1.client端：build模式需要builder和director。 facade模式只需要facade。

2.过程中：builder的行为有一定的规律，这样builder才包含了好多其子类。 facade是没有规律的。subsystem和facade没有关系，其不知道facade存在，将facade当做client。 

如果硬要使 建造者模式和外观模式挂钩：

facade角色 = director角色。

subsystem角色 = builder角色（Concrete Builder角色）