設計模式 外觀模式

2021-08-30 02:01:40 字數 1451 閱讀 8126

1、外觀模式簡介

外觀模式,一般用在子系統與訪問之間,用於對訪問遮蔽複雜的子系統呼叫,採用耳目一新的外觀類提供的簡單的呼叫方法,具體的實現由外觀類去子系統呼叫。

外觀模式任然是一種中介軟體型別的模式,使用外觀模式之後子系統的方法呼叫並非完全遮蔽,只是為訪問者提供了一種更佳的訪問方式,如果你不嫌麻煩,任然可以直接進行子系統方法呼叫。

甚至於在子系統與子系統之間進行呼叫時也可以通過各自的外觀類來進行呼叫,這樣**方便管理。

下面請看**例項:更能顯示這種情況

子系統方法1

1 public class submethod1 

5 }

子系統方法2

1 public class submethod2 

5 }

子系統方法3

1 public class submethod3 

5 }

外觀類:

1 public class facader 

9 public void facmethod2()

14 }

測試類:

1 public class clienter 

8 9 }

其實直接呼叫也會得到相同的結果,但是採用外觀模式能規範**,外觀類就是子系統對外的乙個總介面,我們要訪問子系統是,直接去子系統對應的外觀類進行訪問即可!

2、外觀模式應用場景

當我們訪問的子系統擁有複雜額結構,內部呼叫繁雜,初接觸者根本無從下手時,不凡由資深者為這個子系統設計乙個外觀類來供訪問者使用,統一訪問路徑(集中到外觀類中),將繁雜的呼叫結合起來形成乙個總呼叫寫到外觀類中,之後訪問者不用再繁雜的方法中尋找需要的方法進行呼叫,直接在外觀類中找對應的方法進行呼叫即可。

還有就是在系統與系統之間發生呼叫時,也可以為被呼叫子系統設計外觀類,這樣方便呼叫也,遮蔽了系統的複雜性。

來自另一部落格的理解:

外觀模式的使用場景:

1.首先,在設計初期階段,應該要有意識的將不同的兩個層分離,比如經典的三層架構,就需要考慮在資料訪問層和業務邏輯,業務邏輯層和表示層的層與層之間建立外觀facade(外觀),這樣可以為複雜的子系統提**該簡單的介面,使得耦合大大降低。

2.其次,在開發階段,子系統往往因為不斷的重構演化而變得越來越複雜,大多數的模式使用時也都會產生很多很小的類,這本是好事,但也給外部呼叫它們的使用者程式帶來使用上的困難,增加外觀facade可以提供乙個簡單介面,減少它們之間的依賴。

3.在維護乙個遺留的大型系統時,可能這個系統已經非常難以維護和擴充套件了,但因為它包含非常重要的功能,新的需求開發必須依賴它。此時用外觀模式facade也是非常合適的。你可以為新系統開發乙個外觀facade類,來提供設計粗糙或高度複雜的遺留**的比較清晰簡單的介面,讓新系統與facade物件進行互動,facade與遺留**互動所有複雜的工作。

設計模式 外觀模式

外觀模式,我的理解就是將複雜的類進行重新封裝,將簡單的介面呈現出來,降低呼叫端和實際類的耦合性。拿 大話設計模式 上邊關於 和 的例子來說。對於不入門的股民來說,交易有些過於龐大,需要學習的東西很多,如果沒整明白就進行投資,很容易賠錢的。很多剛入 的股民都賠的很慘。而買 有提出了乙個新的觀念,我們買...

設計模式 外觀模式

何為外觀模式?外觀模式 為子系統中的一組介面提供乙個一致的介面,此模式定義了乙個高層介面,這個介面使得一子系統更加容易使用。它是一種結構型模式,它主要解決的問題是 元件的客戶和元件中各種複雜的子系統有了過多的耦合,隨著外部客戶程式和 各子系統的演化,這種過多的耦合面臨很多變化的挑戰。uml類圖 乙個...

設計模式 外觀模式

外觀模式說白了就是為一組介面提供乙個一致的介面。例如 定義三個類a b c,每個類各定義乙個方法。class a pubic void showa cout a showa pubic void showb cout b showb pubic void showc cout c showc 定義乙...