摘要:外觀模式的目的在于降低系統的復雜程度。在不引入抽象外觀類的情況下,增加新的子系統可能需要修改外觀類或客戶端的源代碼,違背了開閉原則。
外觀模式
外觀模式(Facade Pattern):外部與一個子系統的通信必須通過一個統一的外觀對象進行,為子系統中的一組接口提供一個一致的界面,外觀模式定義了一個高層接口,這個接口使得這一子系統更加容易使用。外觀模式又稱為門面模式,它是一種對象結構型模式。
Laravel中我們常用到的Route、Redis、Auth這些Facade就是外觀模式的具體實現, 在Laravel中設計了多個外觀類,每個外觀類繼承自統一的抽象外觀類,在抽象外觀類里提供了通過外觀類訪問其背后子系統的基礎方法。
對于新的業務需求,不要修改原有外觀類,而應該增加一個新的具體外觀類,由新的具體外觀類來關聯新的子系統對象,同時通過修改配置文件來達到不修改源代碼并更換外觀類的目的。
下面是一個簡單的外觀模式的例子,并沒有引入抽象外觀類,在介紹Laravel Facades的文章中我們會看到Laravel里提供了一個抽象外觀類從而讓我們能夠方便的根據需要增加新子系統的外觀類,并讓外觀類能夠正確代理到其對應的子系統(或者叫服務)。
模式結構外觀模式包含如下角色:
Facade 外觀角色
SubSystem 子系統角色
代碼示例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源碼學習里,歡迎訪問閱讀。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/29143.html
摘要:外觀模式定義了一個高層接口,這個接口使得這一子系統更加容易使用。將使用者與子系統從直接耦合,轉變成由外觀類提供統一的接口給使用者使用,以降低客戶端與子系統之間的耦合度。接下來將深入分析外觀服務的加載過程。引導程序將在處理請求是完成引導啟動。 本文首發于 深入淺出 Laravel 的 Facade 外觀系統,轉載請注明出處。 今天我們將學習 Laravel 核心架構中的另一個主題「Fac...
摘要:本文來自原文鏈接歡迎作客我們的學習群該篇屬于底層核心技術實戰揭秘這一課程底層核心概念解析這一章的擴展閱讀。考慮到學員們的基礎差異,為了避免視頻當中過于詳細而連篇累牘,故將一些底層實現相關的知識點以文章形式呈現,供大家預習和隨時查閱。 本文來自pilishen.com----原文鏈接; 歡迎作客我們的php&Laravel學習群:109256050該篇屬于《Laravel底層核心技術實戰...
摘要:模式定義觀察者模式定義對象間的一種一對多依賴關系,使得每當一個對象狀態發生改變時,其相關依賴對象皆得到通知并被自動更新。 觀察者模式 Laravel的Event事件系統提供了一個簡單的觀察者模式實現,能夠訂閱和監聽應用中發生的各種事件,在PHP的標準庫(SPL)里甚至提供了三個接口SplSubject, SplObserver, SplObjectStorage來讓開發者更容易地實現觀...
摘要:可以為服務提供者的方法設置類型提示。方法將在所有其他服務提供者均已注冊之后調用。所有服務提供者都在配置文件中注冊。可以選擇推遲服務提供者的注冊,直到真正需要注冊綁定時,這樣可以提供應用程序的性能。 本文最早發布于 Rootrl的Blog 導言 Laravel是一款先進的現代化框架,里面有一些概念非常重要。在上手Laravel之前,我認為先弄懂這些概念是很有必要的。你甚至需要重溫下PHP...
摘要:前言年底了不太忙,最近一段時間也一直在研究,就想寫篇關于比較深一點的教程系列啥的,于是就找到站長給開了寫教程的渠道。優點的就是為藝術家創造的框架,它也是工程化的趨勢。項目維護方便也是事實。如果有遇到問題可以直接在教程下面留言。 前言 年底了不太忙,最近一段時間也一直在研究laravel,就想寫篇關于laravel比較深一點的教程系列啥的,于是就找到站長給開了寫教程的渠道。由于第一次寫,...
閱讀 1689·2021-11-23 09:51
閱讀 3205·2021-09-26 10:21
閱讀 805·2021-09-09 09:32
閱讀 887·2019-08-29 16:06
閱讀 3316·2019-08-26 13:36
閱讀 778·2019-08-26 10:56
閱讀 2571·2019-08-26 10:44
閱讀 1151·2019-08-23 14:04