在學習這個模式之前，我們先來回顧一下乙個物件導向的設計原則——迪公尺特原則，這個原則告訴我們：乙個物件盡可能少跟其他物件進行關聯，就像乙個人要少跟陌生人說話一樣。
而中介者模式，也正是為了協調多個物件之間複雜的引用關係。我們來看乙個例子，雖然這個例子不太好，後期想個好一點的例子再改。
在中介者模式中，主要是引入了中介者角色，分別是抽象中介者和具體中介者，封裝了各個物件之間共同的互動方法。
抽象同事類：定義了各個同事類共有的方法，它維持著乙個抽象中介者類的引用。
具體同事類：它是抽象同事類的子類，每乙個同事物件都需要通過中介者與其他同事類進行通訊。
你會發現，這樣我們就重新構造出了一張關係網：
這樣就對同事物件之間的關係行為進行了分離和封裝。
在面向元件開發時，我們經常會使用到一些按鈕、下拉列表、標籤等控制項。問題來了，如果我們希望按鈕一按下，下拉列表就進行改變，或者希望按鈕單擊後，標籤內容就進行改變··· 這就意味著，各個控制項之間需要有乙個關聯的關係。
一般人設計後的關係圖是這樣···
而正確的設計是····
//抽象中介者
abstract class mediator
//具體中介者
public class concretemediator extends mediator
//從列表框選擇客戶
else if(c == image)
//從組合框選擇客戶
else if(c == list)
} }//抽象同事類
abstract class control
public void changed()
public abstract void update();
public abstract void select();
}//具體同事類：按鈕
public class button extends control
public void select()
}//具體同事類：列表
public class list extends control
public void select()
}//具體同事類：
public class image extends control
public void select()
}public class test
}
中介者模式的核心在於，對多個物件之間的互動進行了解耦。缺點相信大家都看到了，如果按照上面去設計，得主動去設定各個控制項之前的關係，**很冗長。而且，具體中介者包含了大量互動的細節，使中介者變得難以維護。
設計模式 中介者模式
假如沒有總經理，下面三個部門 財務部，市場部，研發部。財務部要發工資，讓大家核對公司需要跟市場部和研發部都通氣 市場部要接新專案，需要研發部處理技術 需要財務部出資金。市場部跟各個部門打交道。雖然只有三個部門，但是關係非常亂。實際上，公司都有總經理。各個部門有什麼事情都通報到總經理這裡，總經理再通知...
設計模式 中介者模式
在我們的日常生活中經常需要購買各種各樣的東西，房子 車子 生活用品等等。那麼我們並不會對各個產品都了解，所以銷售人員應運而生，他們了解產品，然後他們根據你的需求在向你們推薦符合你們要求的產品。這些銷售人員就相當於中介，處於客戶和產品之間，為你們搭橋牽線。這就是這篇需要講述的乙個設計模式 中介者模式。...
設計模式 中介者模式
問題 當專案有多個系統或者管理類，他們之間需要互相呼叫的時候，怎麼辦。如果直接在這些系統或者管理類之間互相注入對方的引用，這雖然可以暫時解決問題，但後期會造成 的依賴程度變高，耦合難解，而且單個類知道的引用內容過多，不符合最少只是原則，推薦使用中介者模式解耦和。抽象類如下 中介者介面 public ...