外觀模式引用書中的定義如下：
為子系統中的一組介面提供乙個統一的入口。外觀模式定義了乙個高層介面，這個介面使得這一子系統更加容易使用。合度。外觀模式又稱為門面模式，它是一種物件結構型模式。外觀模式是迪公尺特法則的一種具體實
現，通過引入乙個新的外觀角色可以降低原有系統的複雜度，同時降低客戶類與子系統的耦
對於這個模式的理解，我覺得著重點在於幾個詞上，分別是一組介面、統一入口、降低複雜度。
結合我們目前的系統進行說明,首先說什麼是一組介面。
在我們的系統中，由於業務需要，有三種日誌，分別是系統日誌、告警日誌、監控日誌，我用非正式的**簡單表示如下：
系統日誌類介面定義：
public class loghandle }/**
告警日誌類介面定義：
public class alarmlogservice }/**
監控日誌類介面：
public class monitorlogservice }/**
上邊三個日誌介面為了表示功能的不同，簡單地對日誌內容進行了不同的拼接，實際專案中自然不會這樣。
這三個日誌介面，都是屬於日誌的操作，只是列印出的日誌內容被不同的系統採集再使用，而且他們基本上也都同時被使用到，所以可以說他們就是屬於外觀模式定義中的那一組介面。
在沒有使用外觀模式的情況下，我們在業務**中需要列印日誌的時候可能就會是下邊所示這樣：
public class blogservice catch (exception e) ", new object );/**
alarmlogservice.error("系統異常{}", new object );
monitorlogservice.error("系統異常{}", new object );}}}
public class userservice catch (exception e) ", new object );/**
alarmlogservice.error("系統異常{}", new object );
monitorlogservice.error("系統異常{}", new object );}}}
很顯然，兩個service中有大量重複的**。這裡只有兩個類列印日誌，就需要一共呼叫6次日誌列印方法，每多出乙個類需要列印這樣的日誌，就會以3的倍數增加**。
而且這裡的示例幾乎是最簡單的，在實際業務開發的時候可能就遠不止三行。
同時，像上邊這種做法，假如後續日誌系統增多，需要增加到四種甚至五種或者更多，那個每個列印日誌的類都需要進行相應的修改，很顯然，這是極不利於維護和拓展的。
因此，按照常規的思路，可能就會有兩種做法：
一種是把這種列印日誌的**進行提取，封裝為乙個方法進行呼叫。但是這種做法會存在一定的問題，首先，這個方法本身和業務是無關的，放在業務類中不合適。其次，除非所有需要列印日誌的類都有乙個共同的父類，把這個方法放在父類中，否則就需要定義多次該方法。
於是乎，就有了第二種做法，那就是把這段**提取到另外乙個類中，那麼這個類就是所謂的外觀類了：
public class loghandle }/**
有了這樣乙個類之後，我們的業務**呼叫的時候就只需要一次就可以搞定，而這個管理日誌操作的類就是統一介面。
public class userservice catch (exception e) ", new object );}}}/**
與此同時，如果後續日誌系統變化，不論是增加新的日誌型別，還是刪減舊的日誌型別，都只需要改動loghandle類就可以了，而且每個呼叫日誌的地方**也都減少了很多，這就大大降低了系統的複雜度。
需要有一組介面，他們幾乎都是成套被使用；
乙個外觀類或介面，實際操作上邊的一組介面，而提供乙個公開的介面方法供外部呼叫；
客戶端只需要一次呼叫外觀類的介面，而不需要分別呼叫最開始那一組介面的每乙個。
在沒有學這個模式的時候，我覺得單例模式是最簡單的設計模式，而現在來看，這個似乎才是最簡單的設計模式。
設計模式8 外觀模式
為子系統中的一組介面提供乙個一致的介面，此模式定義了乙個高層介面，這個介面使得這個子系統更加容易使用。public class subsystemone public class subsystemtwo public class subsystemthree public class subsys...
設計模式 8 外觀模式
定義 為子系統中的一組介面提供乙個一致的介面，此模式定義了乙個高層介面，這個介面使得子系統更加容易使用。使用場景 當子系統的介面過於複雜時，比如經典的三層架構，就需要考慮在資料訪問層和業務邏輯層，業務邏輯層和表示層的層與層之間建立外觀。以達到簡化目的，降低耦合 實現 建立外觀類，聚合子系統各個介面，...
Java設計模式8 外觀模式
外觀模式隱藏了系統的複雜性，並向客戶端提供了乙個可以訪問系統的介面。這種型別的設計模式屬於結構性模式。為子系統中的一組介面提供了乙個統一的訪問介面，這個介面使得子系統更容易被訪問或者使用。1 外觀角色 外觀模式的核心。它被客戶角色呼叫，它熟悉子系統的功能。內部根據客戶角色的需求預定了幾種功能的組合。...