外观模式(Facade Pattern)
定义
为子系统中的一组接口提供一个统一的入口。外观模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。
设计的原则和思想
- 解耦的是客户端和子系统。
- 不变部分是子系统,变化部分是多个子系统之间的依赖性。
- 核心思想是封装交互,简化调用。
一句话概括设计模式
为多个业务类的调用提供了一个统一的入口,简化了类与类之间的交互。
结构中包含的角色
- Facade(外观角色)
- 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();
优点
- 客户端代码将变得很简单,与之关联的对象也很少。
- 减少系统相互依赖。
- 可以独立于复杂子系统。
缺点
- 外观者可能与很多类都有耦合,修改代码非常麻烦。
- 新增子系统,可能需要修改外观者的代码,外观者设计难度高,可扩展性低。
何时使用
- 为访问一系列复杂的子系统提供一个简单入口时。
- 将多个接口调用替换为一个门面接口调用,减少网络通信成本,提高 App
- 需要屏蔽系统的底层实现,隐藏系统的复杂性,提供一组更加简单易用、更高层的接口。
- 创建外观来定义子系统中各层次的入口,以减少子系统之间的耦合。
- 需要解耦子系统和客户端。
实际应用场景
- 去医院看病,前台就是外观者。
- Laravel的门面。