laravel框架中的外觀模式(Facade Pattern)是外部與一個子系統的通訊必須透過一個統一的外觀物件進行，為子系統中的一組介面提供一個一致的介面，外觀模式定義了一個高層接口，這個接口使得這個子系統更容易使用。外觀模式又稱為門面模式，它是一種物件結構型模式。
Laravel中我們常用到的Route、Redis、Auth這些Facade就是外觀模式的具體實現， 在Laravel中設計了多個外觀類，每個外觀類別繼承自統一的抽像外觀類，在抽像外觀類別裡提供了透過外觀類別存取其背後子系統的基礎方法。
對於新的業務需求，不要修改原有外觀類，而應該增加一個新的具體外觀類，由新的具體外觀類來關聯新的子系統對象，同時通過修改配置文件來達到不修改原始程式碼並更換外觀類別的目的。
下面是一個簡單的外觀模式的例子，並沒有引入抽像外觀類，在介紹Laravel Facade的文章中我們會看到Laravel裡提供了一個抽像外觀類從而讓我們能夠方便的根據需要增加新子系統的外觀類，並讓外觀類別能夠正確代理到其對應的子系統(或叫服務)。
外觀模式包含以下角色：
Facade 外觀角色
SubSystem 子系統角色
<?php 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()
{
//
}
}根據“單一職責原則”，在軟體中將一個系統劃分為若干個子系統有利於降低整個系統的複雜性，一個常見的設計目標是使子系統間的通信和相互依賴關係達到最小，而達到該目標的途徑之一就是引入一個外觀對象，它為子系統的存取提供了一個簡單而單一的入口。 -外觀模式也是「迪米特法則」的體現，透過引入一個新的外觀類別可以降低原有系統的複雜度，同時降低客戶類別與子系統類別的耦合度。 - 外觀模式要求一個子系統的外部與其內部的通訊透過一個統一的外觀物件進行，外觀類別將客戶端與子系統的內部複雜性分隔開，使得客戶端只需要與外觀物件打交道，而不需要與子系統內部的許多物件打交道。 -外觀模式的目的在於降低系統的複雜程度。 -外觀模式從很大程度上提高了客戶端使用的便利性，使得客戶端無須關心子系統的工作細節，透過外觀角色即可呼叫相關功能。
外觀模式的缺點
不能很好地限制客戶使用子系統類，如果對客戶存取子系統類別做太多的限制則減少了可變性和靈活性。
在不引入抽像外觀類別的情況下，增加新的子系統可能需要修改外觀類別或客戶端的原始程式碼，違反了「開閉原則」。
一個系統有多個外觀類別
在外觀模式中，通常只需要一個外觀類，而此外觀類別只有一個實例，換言之它是一個單例類別。在許多情況下為了節約系統資源，一般將外觀類別設計為單例類別。當然這並不意味著在整個系統裡只能有一個外觀類，在一個系統中可以設計多個外觀類，每個外觀類都負責和一些特定的子系統交互，向用戶提供相應的業務功能。
不要試圖透過外觀類別為子系統增加新行為
不要透過繼承外觀類別在子系統中加入新的行為，這種做法是錯誤的。外觀模式的用意是為子系統提供一個集中化和簡化的溝通管道，而不是向子系統加入新的行為，新的行為的增加應該透過修改原有子系統類別或增加新的子系統類別來實現，不能透過外觀類別來實現。
抽像外觀類別的引入
外觀模式最大的缺點在於違背了“開閉原則”，當增加新的子系統或移除子系統時需要修改外觀類，可以透過引入抽像外觀類別在一定程度上解決該問題，客戶端針對抽像外觀類別進行程式設計。對於新的業務需求，不修改原有外觀類，而對應增加一個新的具體外觀類，由新的具體外觀類來關聯新的子系統對象，同時通過修改配置文件來達到不修改源代碼並更換外觀類別的目的。
在外觀模式中，外部與子系統的通訊必須透過一個統一的外觀物件進行，為子系統中的一組接口提供一個一致的介面，外觀模式定義了一個高層接口，這個接口使得這個子系統更容易使用。外觀模式又稱為門面模式，它是一種物件結構型模式。
外觀模式包含兩個角色：外觀角色是在客戶端直接呼叫的角色，在外觀角色中可以知道相關的(一個或多個)子系統的功能和責任，它將所有從客戶端發來的請求委派到相應的子系統去，傳遞給相應的子系統對象處理；在軟體系統中可以同時有一個或者多個子系統角色，每個子系統可以不是一個單獨的類，而是一個類別的集合，它實現子系統的功能。
外觀模式要求一個子系統的外部與其內部的通訊透過統一的外觀物件進行，外觀類別將客戶端與子系統的內部複雜性分隔開，使得客戶端只需要與外觀物件打交道，而不需要與子系統內部的許多物件打交道。
外觀模式主要優點在於對客戶屏蔽子系統元件，減少了客戶處理的物件數目並使得子系統使用起來更加容易，它實現了子系統與客戶之間的松耦合關係，並降低了大型軟體系統中的編譯依賴性，簡化了系統在不同平台之間的移植過程；其缺點在於不能很好地限制客戶使用子系統類，而且在不引入抽像外觀類的情況下，增加新的子系統可能需要修改外觀類別或客戶端的原始程式碼，違反了「開閉原則」。
外觀模式適用情況包括：要為一個複雜子系統提供一個簡單介面；客戶程式與多個子系統之間存在很大的依賴性；在層次化結構中，需要定義系統中每一層的入口，使得層與層之間不會直接產生聯繫。
以上就是本篇文章的全部內容，更多請關注laravel框架入門教學。
相關文章推薦：
Laravel本地環境搭建：Homestead開發環境的部署
相關課程推薦：
以上是Laravel框架中外觀模式的深入解析的詳細內容。更多資訊請關注PHP中文網其他相關文章！
