外观模式
外观(Facade)模式
当使用子系统的代码时，你也许会发现自己过于深入地调用子系统的逻辑代码。如果子系统代码总是在不断变化，而你的代码却又在许多不同地方与子系统代码交互，那么随着子系统的发展，你也许会发现维护代码变得非常困难。
在项目中集成复杂的第三方代码，或在系统中逐渐形成大量仅在系统自身内部有用的代码，在这些情况下，你总可以应用外观模式，为复杂的系统创建一个简单、清晰的接口。
假设有下面一段很乱的代码，其功能是从文件中获取log信息并将它转换为对象。
用 laravel 框架举例
Laravel中我们常用到的Route、Redis、Auth这些Facade就是外观模式的具体实现， 在Laravel中设计了多个外观类，每个外观类继承自统一的抽象外观类，在抽象外观类里提供了通过外观类访问其背后子系统的基础方法。
class Client
{
public function main()
{
(new Facade)->operation();
}
}
class Facade
{
private $systemA;
private $systemB;
public function __construct()
{
$this->systemA = new SystemA;
$this->systemB = new SystemB;
}
public function operation()
{
$this->systemA->operationA();
$this->systemB->operationB();
}
}
class SystemA
{
public function operationA()
{
//
}
}
class SystemB
{
public function operationB()
{
//
}
}
模式分析
根据“单一职责原则”，在软件中将一个系统划分为若干个子系统有利于降低整个系统的复杂性，一个常见的设计目标是使子系统间的通信和相互依赖关系达到最小，而达到该目标的途径之一就是引入一个外观对象，它为子系统的访问提供了一个简单而单一的入口。 -外观模式也是“迪米特法则”的体现，通过引入一个新的外观类可以降低原有系统的复杂度，同时降低客户类与子系统类的耦合度。 - 外观模式要求一个子系统的外部与其内部的通信通过一个统一的外观对象进行，外观类将客户端与子系统的内部复杂性分隔开，使得客户端只需要与外观对象打交道，而不需要与子系统内部的很多对象打交道。 -外观模式的目的在于降低系统的复杂程度。 -外观模式从很大程度上提高了客户端使用的便捷性，使得客户端无须关心子系统的工作细节，通过外观角色即可调用相关功能。