14.5 最佳實踐 本章講述的中介者模式很少用到接口或者抽象類，這與依賴倒置原則是沖突的，這是什么原因呢？首先，既然是同事類而不是兄弟類（有相同的血緣），那就說明這些類之間是協作關系，完成不同的任務，處理不同的業務，所以不能在抽象類或接口中嚴格定義同事類必須具有的方法（從這點也可以看出繼承是高侵入性的）。這是不合適的，就像你我是同事，雖然我們大家都是朝九晚五地上班，但是你跟我干的活肯定不同，不可能抽象出一個父類統一定義同事所必須有的方法。當然，每個同事都要吃飯、上廁所，可以把這些最基本的信息封裝到抽象中，但這些最基本的行為或屬性是中介者模式要關心的嗎？如果兩個對象不能提煉出共性，那就不要刻意去追求兩者的抽象，抽象只要定義出模式需要的角色即可。當然如果嚴格遵守面向接口編程的話，則是需要抽象的，這就需要讀者在實際開發中靈活掌握。其次，在一個項目中，中介者模式可能被多個模塊采用，每個中介者所圍繞的同事類各不相同，你能抽象出一個具有共性的中介者嗎？不可能，一個中介者抽象類一般只有一個實現者，除非中介者邏輯非常復雜，代碼量非常大，這時才會出現多個中介者的情況。所以，對于中介者來說，抽象已經沒有太多的必要。 中介者模式是一個非常好的封裝模式，也是一個很容易被濫用的模式，一個對象依賴幾個對象是再正常不過的事情，但是純理論家就會要求使用中介者模式來封裝這種依賴關系，這是非常危險的！使用中介模式就必然會帶來中介者的膨脹問題，這在一個項目中是很不恰當的。大家可以在如下的情況下嘗試使用中介者模式： ● N個對象之間產生了相互的依賴關系（N＞2）。 ● 多個對象有依賴關系，但是依賴的行為尚不確定或者有發生改變的可能，在這種情況下一般建議采用中介者模式，降低變更引起的風險擴散。 ● 產品開發。一個明顯的例子就是MVC框架，把中介者模式應用到產品中，可以提升產品的性能和擴展性，但是對于項目開發就未必，因為項目是以交付投產為目標，而產品則是以穩定、高效、擴展為宗旨。