定義
為子系統中的一組介面提供一個統一的入口。外觀模式定義了一個高層介面,這個介面使得這一子系統更加容易使用。
設計的原則和思想
- 解耦的是客戶端和子系統。
- 不變部分是子系統,變化部分是多個子系統之間的依賴性。
- 核心思想是封裝互動,簡化呼叫。
一句話概括設計模式
為多個業務類的呼叫提供了一個統一的入口,簡化了類與類之間的互動。
結構中包含的角色
- 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的門面。
本作品採用《CC 協議》,轉載必須註明作者和本文連結