迪米特法則（Law of Demeter，LoD）也稱為最少知識原則（Least Knowledge
Principle，LKP），雖然名字不同，但描述的是同一個規則：一個物件應該對其他物件有最
少的瞭解。通俗地講，一個類應該對自己需要耦合或呼叫的類知道得最少，你（被耦合或調
用的類）的內部是如何複雜都和我沒關係，那是你的事情，我就知道你提供的這麼多public
方法，我就呼叫這麼多，其他的我一概不關心。

1. 只和朋友交流
迪米特法則還有一個英文解釋是：Only talk to your immediate friends（只與直接的朋友通
信。）什麼叫做直接的朋友呢？每個物件都必然會與其他物件有耦合關係，兩個物件之間的
耦合就成為朋友關係，這種關係的型別有很多，例如組合、聚合、依賴等。下面我們將舉例
說明如何才能做到只與直接的朋友交流。
傳說中有這樣一個故事，老師想讓體育委員確認一下全班女生來齊沒有，就對他
說：“你去把全班女生清一下。”體育委員沒聽清楚，就問道：“呀，……那親哪個？”老師無
語了，我們來看這個笑話怎麼用程式來實現，類圖如圖

package LeastKnowledgeP;

import java.util.ArrayList;
import java.util.List;

public class Teacher {
    public void commemd(GroupLeader groupLeader){
        List listGirls = new ArrayList();
        for (int i=0;i<20;i++){
            listGirls.add(new Girl());
        }
        groupLeader.countGirls(listGirls);
    }
}

package LeastKnowledgeP;

import java.util.List;

public class GroupLeader {
    public void countGirls(List<Girl> listGirls){
        System.out.println("num is :"+listGirls.size());
    }
}

package LeastKnowledgeP;

public class Girl {
}

package LeastKnowledgeP;

public class Client {
    public static void main(String[] args){
        Teacher teacher = new Teacher();
        teacher.commemd(new GroupLeader());
    }
}

4. 謹慎使用Serializable

在實際應用中，這個問題是很少出現的，即使出現也會立即被發現並得到解決。是怎麼
回事呢？舉個例子來說，在一個專案中使用RMI（Remote Method Invocation，遠端方法調
用）方式傳遞一個VO（Value Object，值物件），這個物件就必須實現Serializable介面（僅
僅是一個標誌性介面，不需要實現具體的方法），也就是把需要網路傳輸的物件進行序列
化，否則就會出現NotSerializableException異常。突然有一天，客戶端的VO修改了一個屬性
的訪問許可權，從private變更為public，訪問許可權擴大了，如果伺服器上沒有做出相應的變
更，就會報序列化失敗，就這麼簡單。但是這個問題的產生應該屬於專案管理範疇，一個類
或介面在客戶端已經變更了，而伺服器端卻沒有同步更新，難道不是專案管理的失職嗎？

        迪米特法則的核心觀念就是類間解耦，弱耦合，只有弱耦合了以後，類的複用率才可以
提高。其要求的結果就是產生了大量的中轉或跳轉類，導致系統的複雜性提高，同時也為維
護帶來了難度。我們在採用迪米特法則時需要反覆權衡，既做到讓結構清晰，又做到高內聚
低耦合。

不知道大家有沒有聽過這樣一個理論：“任何兩個素不相識的人中間最多隻隔著6個人，
即只通過6個人就可以將他們聯絡在一起”，這就是著名的“六度分隔理論”。如果將這個理論
應用到我們的專案中，也就是說，我和我要呼叫的類之間最多有6次傳遞。呵呵，這隻能讓
大家當個樂子來看，在實際應用中，如果一個類跳轉兩次以上才能訪問到另一個類，就需要
想辦法進行重構了，為什麼是兩次以上呢？因為一個系統的成功不僅僅是一個標準或是原則
就能夠決定的，有非常多的外在因素決定，跳轉次數越多，系統越複雜，維護就越困難，所
以只要跳轉不超過兩次都是可以忍受的，這需要具體問題具體分析。