外观模式（Facade Pattern）

定义

为子系统中的一组接口提供一个统一的入口。外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

设计的原则和思想

1. 解耦的是客户端和子系统。
2. 不变部分是子系统，变化部分是多个子系统之间的依赖性。
3. 核心思想是封装交互，简化调用。

一句话概括设计模式

为多个业务类的调用提供了一个统一的入口，简化了类与类之间的交互。

结构中包含的角色

1. Facade（外观角色）
2. SubSystem（子系统角色）

最小可表达代码

class SubSystemA
{
    public function executeA()
    {
        echo 'SubSystemA : executeA;';
    }
}

class SubSystemB
{
    public function executeB()
    {
        echo 'SubSystemB : executeB;';
    }
}

class Facade  
{  
    private $subSystemA;
    private $subSystemB;

    public function __construct()
    {  
        $this->subSystemA = new SubSystemA();
        $this->subSystemB = new SubSystemB();
    }

    public function execute()
    {
        $this->subSystemA->executeA();
        $this->subSystemB->executeB();
    }
}

(new Facade())->execute();

优点

1. 客户端代码将变得很简单，与之关联的对象也很少。
2. 减少系统相互依赖。
3. 可以独立于复杂子系统。

缺点

1. 外观者可能与很多类都有耦合，修改代码非常麻烦。
2. 新增子系统，可能需要修改外观者的代码，外观者设计难度高，可扩展性低。

何时使用

1. 为访问一系列复杂的子系统提供一个简单入口时。
2. 将多个接口调用替换为一个门面接口调用，减少网络通信成本，提高 App
3. 需要屏蔽系统的底层实现，隐藏系统的复杂性，提供一组更加简单易用、更高层的接口。
4. 创建外观来定义子系统中各层次的入口,以减少子系统之间的耦合。
5. 需要解耦子系统和客户端。

实际应用场景

1. 去医院看病，前台就是外观者。
2. Laravel的门面。

本作品采用《CC 协议》，转载必须注明作者和本文链接