http://www.cnblogs.com/sweetdream/archive/2005/12/19/299983.html

門面（Facade）模式和中介者(Mediator)模式有著共同的目的。它們都是調配一組相互耦合的對象的通信。不過門面模式關注的是這組復雜對象如何與外界通信，而中介者模式是調配這組復雜對象之間的通信。

門面（Facade）模式
??????? 當想要為一組具有復雜且全面的接口對象提供一個簡單且特定的接口供外界使用時，就可以采用門面模式。
??????? 門面模式理解起來不難，但是要找到合適粒度的門面就不那么容易了。[GOF95]中說：“一個常見的設計目標是使子系統間的通信和相互依賴關系達到最小達到該目標的途徑之一就是引入一個門面對象，它為子系統中較一般的設施提供了一個單一而簡單的界面。”我覺得，雖然用戶不必直接和子系統中的類打交道了，但是通過門面也間接地和它們有所聯系(這里可能可以用Adapter模式隔離變化)。門面模式的主要目的我覺得不在于減少依賴關系(如果包括間接依賴)，而是簡化用戶的使用接口。門面模式是有悖于接口隔離原則的。但是話說回來如果門面選擇的粒度合適的話那么還是利大于弊的。
?
?門面模式的應用:
??????? 當你要為一個復雜子系統提供一個簡單接口時。子系統往往因為不斷演化而變得越來越復雜。大多數模式使用時都會產生更多更小的類。這使得子系統更具可重用性，也更容易對子系統進行定制，但這也給那些不需要定制子系統的用戶帶來一些使用上的困難。Facade可以提供一個簡單的缺省視圖，這一視圖對大多數用戶來說已經足夠，而那些需要更多的可定制性的用戶可以越過Facade層。
??????? 引入Facade將這個子系統與客戶以及其他的子系統分離，可以提高子系統的獨立性和可移植性。
??????? 當你需要構建一個層次結構的子系統時，使用Facade模式定義子系統中每層的入口點，如果子系統之間是相互依賴的，你可以讓它們僅通過Facade進行通訊，從而簡化了它們之間的依賴關系。

門面模式的結構:

?門面(Facade)角色：客戶端可以調用這個角色的方法。此角色知曉相關的(一個或者多個)子系統的功能和責任。在正常情況下，本角色會將所有從客戶端發來的請求委派到相應的子系統去。

?子系統(subsystem)角色：可以同時有一個或者多個子系統。每一個子系統都不是一個單獨的類，而是一個類的集合。每一個子系統都可以被客戶端直接調用，或者被門面角色調用。子系統并不知道門面的存在，對于子系統而言，門面僅僅是另外一個客戶端而已。
???? 注意，可以用抽象類實現Fa?ade而它的具體子類對應于不同的子系統實現，這可以進一步降低客戶與子系統得耦合度。這樣，客戶就可以通過抽象的Fa?ade類接口與子系統通訊。這種抽象耦合關系使得客戶不知道它使用的是子系統得那一個實現。

中介者(Mediator)模式
????? ?用一個中介對象來封裝一系列對象(此模式中稱為Colleague)交互。中介者使各對象不需要顯示地相互引用，從而使其耦合松散，而且可以獨立地改變它們之間的交互(只須改變中介者類)。<<Java與模式>>中有個比較形象的例子，就是中國加入WTO后，與外國的貿易往來都不必和每個國家達成協商，而只要符合WTO的協議就可以了。WTO在這里起了一個中介者的作用。
????? 考慮一個窗體，其中有很多控件，Button，TextBox，ListBox等，這些控件都是相互作用的，比如如果TextBox中沒有字符的話，那么Button的狀態就為UnEnable，當改變ListBox的選項時，TextBox中會顯示ListBox中所選定的項。如果按常規設計這些對象之間的關系就會變得復雜而且不好管理，沒有第三者來組織它們，造成高度的耦合，最壞的情況下，每個對象都要知道其它的對象，可維護性大打折扣；而且要把相互作用的邏輯封裝到自己的類中，重用的可能性也就大打折扣了。
??????? 我們可以通過將集體行為封裝在一個單獨的中介者對象中以避免這個問題。中介者負責控制和協調一組對象間的交互。中介者充當一個中介以使組中的對象不再相互顯示引用。這些對象僅知道中介者，從而減少了相互連接的數目。
?
?中介者模式的結構:

?
?Mediator(中介者)?
????? 中介者定義一個接口用于與各同事(Colleague)對象通信。
?ConcreteMediator(具體中介者)
????? 具體中介者通過協調各同事對象實現協作行為。
????? 了解并維護它的各個同事。
?Colleague(同事類)
?????? 每一個同事類都知道它的中介者對象。
?????? 每一個同事對象在需與其他的同事通信的時候，僅僅與它的中介者通信。?
???????
????? 協作：同事向一個中介者對象發送和接收請求。中介者在各同事間適當地轉發請求以實現協作行為。
????? 從結構圖我們可以看出中介者知道所有同事類，從而才能調度它們，因此可以說中介者模式是將交互的復雜性變成中介者的復雜性。反過來每個同事類都知道它的中介者對象，這樣它才能當自己狀態改變時通知給中介者，從而影響其它的同事類。(這里有兩種實現的方式1.? 可以用到Observer模式；2.? 在Mediator中定義一個特殊的通知接口，各Colleague在通信時直接調用這個接口并將自身作為一個參數傳遞給Mediator，使其可以識別發送者。 )。這樣的耦合性似乎和Fa?ade模式一樣有悖于接口隔離原則的：如果一個同事類的接口改變，那么中介者也將改變，從而使得所有的同事類都要改變。這里是一個循環依賴，每個類接口的改變都可能造成所有類都改變。但是本模式的主要目的之一是簡化通信方式，而不是隔離同事類的變化。我們看看GOF描述這個模式的適用性：
??????? 1.一組對象以定義良好（注意這里說了是定義良好，如果同事類需要經常改變接口就要小心了）但是復雜的方式進行通信。產生的相互依賴關系結構混亂且難以理解。
??????? 2.一個對象引用其他很多對象并且直接與這些對象通信，導致難以復用該對象。(一個對象如果和太多的其它對象相關聯就很難復用了)
??????? 3.想定制一個分布在多個類中的行為，而又不想生成太多的子類。(比如上面說的改變一個控件的狀態就可以引起其它控件的變化)
?????
???? 中介者模式的優點和缺點:
?1．減少子類的生成?? Mediator將原本分布于多個對象間的行為集中在一起。改變這些行為只需生成Mediator的子類即可。
?2．它將各Colleague解耦? Mediator有利于各Colleague類間的松耦合。你可以獨立的改變和復用各Colleague類和Mediator類。
?3．它簡化了對象協議?? 用Mediator和各Colleague間的一對多的交互來替代多對多的交互。一對多的關系更易于理解。維護和擴展。
?4．它對對象如何協作進行了抽象?? 將中介作為一個獨立的概念并將其封裝在一個對象中，使你將注意力從對象各自本身的行為轉移到他們之間的交互上來。這有助于弄清楚一個系統中的對象是如何交互的。
?5．它使控制集中化?? 中介者模式將交互的復雜性變為中介者的復雜性。因為中介者封裝了協議，它可能比任何一個Colleague都復雜。這可能使得中介者自身成為一個難于維護的龐然大物。

Facade模式是解耦系統外到系統內（單向）的對象關聯關系，Mediator模式是解耦系統內各個對象之間在（雙向）的關聯關系

總結

以上是生活随笔為你收集整理的Facade与Mediator模式的区别的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。