Laravel框架中外觀模式的深入解析

laravel框架中的外觀模式(facade pattern)是外部與一個子系統的通信必須通過一個統一的外觀對象進行,為子系統中的一組接口提供一個一致的界面,外觀模式定義了一個高層接口,這個接口使得這一子系統更加容易使用。外觀模式又稱為門面模式,它是一種對象結構型模式。

laravel中我們常用到的Route、redis、Auth這些Facade就是外觀模式的具體實現, 在Laravel中設計了多個外觀類,每個外觀類繼承自統一的抽象外觀類,在抽象外觀類里提供了通過外觀類訪問其背后子系統的基礎方法。

對于新的業務需求,不要修改原有外觀類,而應該增加一個新的具體外觀類,由新的具體外觀類來關聯新的子系統對象,同時通過修改配置文件來達到不修改源代碼并更換外觀類的目的。

下面是一個簡單的外觀模式的例子,并沒有引入抽象外觀類,在介紹Laravel Facade的文章中我們會看到Laravel里提供了一個抽象外觀類從而讓我們能夠方便的根據需要增加新子系統的外觀類,并讓外觀類能夠正確代理到其對應的子系統(或者叫服務)。

模式結構

外觀模式包含如下角色:

  • Facade 外觀角色

  • SubSystem 子系統角色

Laravel框架中外觀模式的深入解析

代碼示例

<?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()     {         //     } }

模式分析

根據“單一職責原則”,在軟件中將一個系統劃分為若干個子系統有利于降低整個系統的復雜性,一個常見的設計目標是使子系統間的通信和相互依賴關系達到最小,而達到該目標的途徑之一就是引入一個外觀對象,它為子系統的訪問提供了一個簡單而單一的入口。 -外觀模式也是“迪米特法則”的體現,通過引入一個新的外觀類可以降低原有系統的復雜度,同時降低客戶類與子系統類的耦合度。 – 外觀模式要求一個子系統的外部與其內部的通信通過一個統一的外觀對象進行,外觀類將客戶端與子系統的內部復雜性分隔開,使得客戶端只需要與外觀對象打交道,而不需要與子系統內部的很多對象打交道。 -外觀模式的目的在于降低系統的復雜程度。 -外觀模式從很大程度上提高了客戶端使用的便捷性,使得客戶端無須關心子系統的工作細節,通過外觀角色即可調用相關功能。

缺點

外觀模式的缺點

  • 不能很好地限制客戶使用子系統類,如果對客戶訪問子系統類做太多的限制則減少了可變性和靈活性。

  • 在不引入抽象外觀類的情況下,增加新的子系統可能需要修改外觀類或客戶端的源代碼,違背了“開閉原則”。

模式擴展

  • 一個系統有多個外觀類

    在外觀模式中,通常只需要一個外觀類,并且此外觀類只有一個實例,換言之它是一個單例類。在很多情況下為了節約系統資源,一般將外觀類設計為單例類。當然這并不意味著在整個系統里只能有一個外觀類,在一個系統中可以設計多個外觀類,每個外觀類都負責和一些特定的子系統交互,向用戶提供相應的業務功能。

  • 不要試圖通過外觀類為子系統增加新行為

    不要通過繼承一個外觀類在子系統中加入新的行為,這種做法是錯誤的。外觀模式的用意是為子系統提供一個集中化和簡化的溝通渠道,而不是向子系統加入新的行為,新的行為的增加應該通過修改原有子系統類或增加新的子系統類來實現,不能通過外觀類來實現。

  • 抽象外觀類的引入

    外觀模式最大的缺點在于違背了“開閉原則”,當增加新的子系統或者移除子系統時需要修改外觀類,可以通過引入抽象外觀類在一定程度上解決該問題,客戶端針對抽象外觀類進行編程。對于新的業務需求,不修改原有外觀類,而對應增加一個新的具體外觀類,由新的具體外觀類來關聯新的子系統對象,同時通過修改配置文件來達到不修改源代碼并更換外觀類的目的。

總結

  • 在外觀模式中,外部與一個子系統的通信必須通過一個統一的外觀對象進行,為子系統中的一組接口提供一個一致的界面,外觀模式定義了一個高層接口,這個接口使得這一子系統更加容易使用。外觀模式又稱為門面模式,它是一種對象結構型模式。

  • 外觀模式包含兩個角色:外觀角色是在客戶端直接調用的角色,在外觀角色中可以知道相關的(一個或者多個)子系統的功能和責任,它將所有從客戶端發來的請求委派到相應的子系統去,傳遞給相應的子系統對象處理;在軟件系統中可以同時有一個或者多個子系統角色,每一個子系統可以不是一個單獨的類,而是一個類的集合,它實現子系統的功能。

  • 外觀模式要求一個子系統的外部與其內部的通信通過一個統一的外觀對象進行,外觀類將客戶端與子系統的內部復雜性分隔開,使得客戶端只需要與外觀對象打交道,而不需要與子系統內部的很多對象打交道。

  • 外觀模式主要優點在于對客戶屏蔽子系統組件,減少了客戶處理的對象數目并使得子系統使用起來更加容易,它實現了子系統與客戶之間的松耦合關系,并降低了大型軟件系統中的編譯依賴性,簡化了系統在不同平臺之間的移植過程;其缺點在于不能很好地限制客戶使用子系統類,而且在不引入抽象外觀類的情況下,增加新的子系統可能需要修改外觀類或客戶端的源代碼,違背了“開閉原則”。

  • 外觀模式適用情況包括:要為一個復雜子系統提供一個簡單接口;客戶程序與多個子系統之間存在很大的依賴性;在層次化結構中,需要定義系統中每一層的入口,使得層與層之間不直接產生聯系。

? 版權聲明
THE END
喜歡就支持一下吧
點贊10 分享