Java 中介者模式實戰：將多對多混亂依賴重構為星狀結構，降低系統耦合度

中介者模式用一個中介對象封裝一組對象的交互，將網狀依賴轉為星狀結構。本文以「跨部門協作」為例，展示部門間通過中介者協調，而非直接耦合，附迪米特法則合規性分析與 MVC 中 Controller 作為中介者的架構映射。

問題背景

N 個部門兩兩可能交互 → N×(N-1) 條依賴關係。新增部門需修改所有相關部門代碼，維護噩夢。

核心代碼實現

// 同事類：部門
class Department {
    private String name;
    private Mediator mediator;
    public Department(Mediator mediator, String name) {
        this.mediator = mediator; this.name = name;
    }
    // 發起請求
    public void request(String task, String targetDeptKey) {
        System.out.println("[" + name + "] 需要協助：" + task);
        mediator.coordinate(this, task, targetDeptKey);
    }
    // 處理請求
    public void handle(String fromDept, String task) {
        System.out.println("[" + name + "] 收到 " + fromDept + " 請求：" + task + " → 立即處理");
        System.out.println("-----------------------------------");
    }
}

// 中介者：協調中心
class Mediator {
    private Map<String, Department> depts = new HashMap<>();
    public void register(Department dept, String key) { depts.put(key, dept); }
    public void coordinate(Department from, String task, String targetKey) {
        Department target = depts.get(targetKey);
        if (target != null) target.handle(from.name, task);
    }
}

// 客戶端
public class Demo {
    public static void main(String[] args) {
        Mediator m = new Mediator();
        Department dev = new Department(m, "開發部");
        Department fin = new Department(m, "財務部");
        Department ops = new Department(m, "運營部");
        
        m.register(dev, "dev");
        m.register(fin, "fin");
        m.register(ops, "ops");
        
        fin.request("專案需要開發資源", "dev");   // 財務 → 開發
        dev.request("開發完成需資金支持", "fin"); // 開發 → 財務
        dev.request("上線需要運營配合", "ops");   // 開發 → 運營
        ops.request("宣傳需要預算", "fin");       // 運營 → 財務
    }
}

迪米特法則合規性驗證

• 最少知識原則：部門只知道中介者，不知其他部門存在
• 只與直接朋友通信：部門 → 中介者（朋友），不直接 → 其他部門（陌生人）
• 降低耦合：新增部門只需在中介者註冊，零修改現有部門代碼

中介者 vs 代理 模式辨析

企業級應用映射

• MVC 架構：Controller 充當 Model 與 View 的中介者
• 事件總線：Guava EventBus / Spring ApplicationEvent 充當異步中介者
• 微服務網關：API Gateway 充當客戶端與多後端服務的中介者
• 聊天室服務端：訊息分發中心

避坑指南

1. 中介者膨脹：邏輯過多導致「上帝類」，需拆分為多個專責中介者
2. 過度使用：對象間交互本身簡單時，直接引用更清晰
3. 循環依賴：同事類持有中介者引用，中介者持有同事引用，構造期需兩階段初始化

中介者模式是「降低耦合」的強力工具，適用於交互複雜、參與者多變的協作場景。