二外觀模式

外觀模式也比較簡單。

外觀模式(facade)：為子系統中的一組介面提供乙個一致的介面，此模式定義了乙個高層介面，這個介面使得這一子系統更加容易的使用。

通過上面對外觀模式的描述，很容易就想到zuul閘道器，通過閘道器的一系列呼叫來達到實現某個目標的需求。外觀模式也是一樣的。外界的呼叫者不用知道呼叫的具體細節，呼叫某個方法就可以。

舉個栗子：

電腦是cup、記憶體、硬碟的外觀。有了外觀以後，啟動電腦和關閉電腦都簡化了。

啟動電腦（按一下電源鍵）：啟動cpu、啟動記憶體、啟動硬碟

關閉電腦（按一下電源鍵）：關閉硬碟、關閉記憶體、關閉cpu

硬碟類：

public class disk 
public void 
end() 
}

cpu類：

public class cpu 
public void 
end() 
}

記憶體類：

public class memory 
public void 
end() 
}

電腦類：

public class computer 
public void 
start() 
public void 
close() 
}

當我們啟動電腦的時候需要呼叫start方法就可以了，無需關注內部發生了什麼。我們也可以為computer建立乙個介面，在外界呼叫的時候使用介面就可以。可能有不同的電腦啟動方式不一樣，那麼我們只需要實現computer的介面，重寫乙個實現類，這樣就可以降低類之間的耦合度。

外觀模式完美的體現了依賴反轉(spring ioc)和迪公尺特法則的思想。

迪公尺特法則:如果兩個類不必彼此直接通訊，那麼這兩個類就不應當發生直接的相互作用。如果其中乙個類需要呼叫另乙個類的某乙個方法的話，可以通過第三者**這個呼叫。

適用場景：大話設計模式的原話

分三個階段，首先，在設計業務初期階段，應該有意識的將不同的兩個層分離，比如經典的三層架構，就需要考慮在資料訪問層和業務邏輯層、業務邏輯層和表示層的層與層之間建立外觀facade(也就是mvc模式),這樣可以為複雜的子系統提**該簡單的介面，使得耦合大大降低。其次，在開發階段，子系統往往因為不斷重構演化而變的越來越複雜，大多數的模式使用時也會都產生很多很小的類，這本是好事，但也給外部呼叫它們的使用者程式帶來了使用上的困難，增加乙個外觀facade可以提**該簡單的介面，減少它們之間的依賴。第三，在維護乙個遺留的大型系統時，可能這個系統已經非常難以維護和擴充套件了，但因為它包含非常重要的功能，新的需求開發必須要依賴它，此時用外觀模式facade也是非常合適的。你可以為新系統開發乙個外觀facade類，來提供設計粗糙或高度複雜的遺留**的比較清晰簡單的介面，讓新系統與facade物件互動，facade與遺留**互動所有複雜的工作。

努力吧，皮卡丘

二外觀模式

狀態模式二外觀模式

設計模式（二）外觀模式 Facade

設計模式（二） Facade模式（外觀模式）

二 外觀模式

狀態模式二 外觀模式

設計模式（二） 外觀模式 Facade

設計模式（二） Facade模式（外觀模式）

相關推薦

二外觀模式

狀態模式二外觀模式

設計模式（二）外觀模式 Facade