嘮叨幾句：設計模式的案例我已經寫過大部分的案例，但是本人沒有經常寫部落格的習慣，最近在將本人之前在碼雲上的案例直接搬過來
個人感覺容易和外觀模式弄混，所以在這裡做下簡單的比較
外觀模式：本質封裝互動，組合呼叫。就是向外部提供一組功能，但是具體的實現比較複雜，內部有喝多的元件相互組合呼叫，強調的是外觀介面，內部可能會有多種實現。為複雜的系統呼叫提供乙個統一介面，降低系統與客戶端的耦合度，使得客戶端呼叫非常方便。外觀模式
中介者模式：將多個物件之間的行為互動（相關業務）放在這裡統一管理（因為放在某個需要互動物件中也不合適），這裡可以使用介面，這樣互動的定義可以有多種實現本質：讓物件的職責更加的單一，將物件直接的資料互動交於乙個統一類來管理， 類似於做業務的service層（dao層獲得的pojo的資料互動都在這裡）≈ 變形
//抽象父類，這是乙個抽象的業務辦理者的介面，裡面實現金錢的操作，
//也可以定義乙個介面，說明需要中介服務的人都有相應的介面
public
abstract
class
people
public
void
setmoney
(int money)
protected
void
addmoney
(int a)
@override
public string tostring()
';}}
//中介者1 孩子
public
class
child
extends
people';
}}
//中介者2 父親
public
class
father
extends
people';
}}
//實現轉賬的業務，這是乙個中介者（中介），提供轉賬服務。這裡的轉賬可以是其他的業務，這裡只是為了方便
//介紹，選擇了這個案例
public
class
moneymediator
}
//測試得客戶端
public
class
mediatorclient
}
設計模式之中介者模式
1 抽象中介者，mediator 抽象中介 author jin.li public abstract class mediator2 具體的中介者，主機板 主機板中介 author jin.li public class mainboard extends mediator if colleagu...
設計模式之中介者模式
中介者模式 假如沒有總經理，下面六個個部門，財務部 市場部 研發部，財務部要發工資，讓大家核對公司需要跟市場部和研發部都通氣，市場部要接個新專案，需要研發部門處理技術，需要財務部出資金，市場部跟各個部門打交道，雖然只有六個個部門，但是關係非常亂 實際上，公司有總經理，各個部門有什麼事情都通報給總結裡...
設計模式之中介者模式
提供乙個中介物件出來，用於封裝一系列物件的互動，從而使各物件不需要直接互動，進一步降低了物件間的耦合度。這是一種行為型設計模式。由此可見，中介者模式主要解決的是物件間所存在的大量關係，我們都知道，物件間一旦關聯緊密，必然會導致系統的複雜性增加，一旦某個物件有所修改，其關聯物件也有可能會有跟著更改，這...