Java 設計模式：中介者模式全面解析

生活中的中介者

房仲媒合租屋雙方、留學中介協助申請流程——中介者的核心價值在於降低雙方直接依賴，提供統一協調介面。軟體設計中同樣面臨：物件之間錯綜複雜的網狀依賴，導致系統難以維護、擴展與重用。

模式定義與核心角色

GoF 定義：用一個中介物件封裝一系列物件的交互。中介者使各物件不需顯式相互引用，從而降低耦合，並能獨立改變它們之間的交互。

三大核心角色

類別結構圖

深度探討：何時使用、何時避免

與相關模式比較

適用時機

• 一組物件以定義良好但複雜的方式通訊，產生難以理解的依賴網
• 多對多交互導致物件難以獨立重用
• 需集中控制交互邏輯（如：表單驗證協調、聊天室訊息分發、航管系統）

潛在風險與對策

風險：具體中介者可能膨脹為「上帝類別」，集中過多業務邏輯。
對策：

• 嚴格控制中介者職責範圍，僅處理「協調邏輯」，業務規則下沉到同事類別
• 若邏輯過於複雜，考慮拆分為多個專職中介者，或引入狀態機、規則引擎
• 評估是否為「過度設計」——若依賴關係本身清晰簡單，直接引用更佳

架構級應用：MVC 中的 Controller 即中介者

MVC 三層中，Controller（控制層）扮演 View 與 Model 之間的中介者：

• View 不直接操作 Model，而是觸發 Controller 動作
• Controller 協調 Model 更新，再通知 View 重繪
• 實現了表現邏輯與業務邏輯的解耦，符合中介者模式精神

總結

中介者模式是「適度解耦」的藝術。它不是萬能藥，而是針對物件群內部交互複雜化的精準手術刀。善用它能讓系統通訊協議從「多對多」簡化為「一對多」，顯著提升可讀性與可維護性；濫用它則會製造出難以維護的中心化巨石。設計時請記住：恰到好處，過猶不及。