迪米特法則實戰：集團公司打印員工 ID 的重構案例

案例背景

某集團公司包含總公司與分公司，需打印所有下屬單位員工 ID。初版設計直接在總公司管理類中遍歷分公司員工列表，違反迪米特法則。

違反原則的初版代碼

class CompanyManager {
    public void printAllEmployee(SubCompanyManager sub) {
        // 直接訪問陌生類 SubEmployee，耦合度極高
        List<SubEmployee> list1 = sub.getAllEmployee();
        for (SubEmployee e : list1) System.out.println(e.getId());
        // ...
    }
}

問題：CompanyManager 與 SubEmployee 無直接關聯（非成員變量/參數/返回值），屬「陌生類」。分公司員工變動會波及總公司代碼。

遵循迪米特法則的重構

核心思想：只與直接朋友通訊。總公司只認識分公司管理類，由分公司負責打印本單位員工。

class SubCompanyManager {
    // 新增：封裝打印邏輯
    public void printEmployee() {
        List<SubEmployee> list = this.getAllEmployee();
        for (SubEmployee e : list) System.out.println(e.getId());
    }
}

class CompanyManager {
    public void printAllEmployee(SubCompanyManager sub) {
        sub.printEmployee(); // 委託直接朋友處理
        List<Employee> list2 = this.getAllEmployee();
        for (Employee e : list2) System.out.println(e.getId());
    }
}

法則七條核心準則

1. 類劃分上創建弱耦合類
2. 類結構設計降低成員訪問權限
3. 優先設計為不可變類
4. 對其他類引用降到最低
5. 降低類訪問權限
6. 謹慎使用序列化
7. 不暴露類成員，提供訪問器

權衡與避坑指南

• 過度應用弊端：引入大量「中介/傳遞類」，系統複雜度上升，通訊效率下降。
• 實戰策略：在「結構清晰」與「高內聚低耦合」間反覆權衡，關鍵路徑嚴守，非核心路徑適度妥協。

總結

迪米特法則本質是封裝變化、降低耦合。通過「中介者」轉發請求，雖增加間接層，但換來系統穩定性與可維護性的提升。實戰中需警惕「為模式而模式」，以業務邊界為準繩劃分直接朋友圈。