說到了門面模式，有些地方又叫做外觀模式，這個模式在平時做web專案中應該是經常用到，像我們的service層與dao層，就是用到了門面模式，controller層本來是需要跟乙個個dao打交道，但是有了service層，它直接與dao打交道，controller就可以直接使用service，我們只需專注在service上寫業務邏輯與操作dao的各種方法，分離了責任，這個模式我認為最重要的功能就是解耦，降低了系統複雜度。
定義：外觀模式是軟體工程中常用的一種軟體設計模式。它為子系統中的一組介面提供乙個統一的高層介面。這一介面使得子系統更加容易使用。
我們可以從定義與類圖知道，門面模式就是為所有的子系統提供乙個統一的高層的介面，負責子系統集合的功能的使用，下面舉個例子，更清晰的了解這個模式。這裡我舉個在京東買鍵盤滑鼠的例子。
首先是各個子系統，也就是各個京東的店家，有賣電腦的實體店，有賣鍵盤的實體店。
package test;
public class computerstore
public void sendcomputer()
}
package test;
public class keyboardstore
public void sendshoes()
}
package test;
public class jingdong
public void buycomputer()
public void buykeyboard()
}
package test;
public class client
}
客戶端是不是很簡單，這裡客戶端只需要跟門面（某東）打交道，不需要本人特地去實體店進行購物，這也體現了**的便利。如果沒有門面（某東），客戶端需要自己去new乙個電腦店，然後再呼叫電腦店的兩個方法，這樣客戶端就依賴具體的子系統（電腦店），其實有做過web專案的應該都很清楚這個模式，正如開頭所說它讓controller與dao解耦，具體的dao操作sql查詢的業務邏輯放到了service這個門面上去實現，具體的客戶端（controller）只需要呼叫service這個門面實現好了的方法即可。
在實際使用的時候，介面不是必須的，就像我上面舉的例子，為了便捷就沒寫介面了，實際上根據依賴倒置原則，無論高層的外觀層，還是底層的子系統，都應該依賴於抽象（介面），這會使得**規範，便於維護，面向介面程式設計相信設計模式學到這裡都能感受到其強大之處，但缺點是介面會增多，複雜性就增加了，而且我們會經常給service裡新增方法，比如查詢***，更新***，這樣需要經常修改介面，這該怎麼辦呢，一般是等介面的行為穩定的時候，在**重構的階段再決定是否新增抽象的介面，應該是乙個解決方式。
設計模式之門面模式 外觀模式
當類a和多個類互動時，並且呼叫其方法很亂時，為了降低類之間的耦合性，符合迪公尺特最少知識法則，專門抽出乙個類，並且提供出幾個簡單明瞭的介面給a類，那麼具體的複雜方法呼叫交給此類進行管理，該類就是為門面類。在開發的時候，我們採用分層思想，控制層 邏輯層 持久層。每層之間使用門面類進行互動。還有就是在開...
設計模式之門面模式 外觀模式
將乙個或數個類的複雜的一切都隱藏在背後，只顯露乙個乾淨美好的門面 外觀 門面沒有封裝子系統的類，門面只提供簡化的介面。所以客戶覺得有必要，依然可以直接使用子系統的類。建立乙個介面簡化而統一的類，用來包裝子系統中的乙個或多個複雜的類。門面模式為子系統提供了一組統一的介面，定義一組高層介面讓子系統更易用...
JAVA設計模式之門面模式（外觀模式）
現代的軟體系統都是比較複雜的，設計師處理複雜系統的乙個常見方法便是將其 分而治之 把乙個系統劃分為幾個較小的子系統。如果把醫院作為乙個子系統，按照部門職能，這個系統可以劃分為 門診 劃價 化驗 收費 取藥等。看病的病人要與這些部門打交道，就如同乙個子系統的客戶端與乙個子系統的各個類打交道一樣，不是一...