6大設計原則之5--迪米特法則

迪米特法則的定義

迪米特法則（Law of Demeter，LoD）也稱爲最少知識原則（Least Knowledge Principle，LKP），雖然名字不一樣，但描述的是同一個規則：一個對象應該對其餘對象有最 少的瞭解。通俗地講，一個類應該對本身須要耦合或調用的類知道得最少，你（被耦合或調 用的類）的內部是如何複雜都和我不要緊，那是你的事情，我就知道你提供的這麼多public 方法，我就調用這麼多，其餘的我一律不關心。

迪米特法則對類的低耦合提出了明確的要求，其包含如下4層含義。

• 只和朋友交流：迪米特法則還有一個英文解釋是：Only talk to your immediate friends（只與直接的朋友通 信。）什麼叫作直接的朋友呢？每一個對象都必然會與其餘對象有耦合關係，兩個對象之間的 耦合就成爲朋友關係，這種關係的類型有不少，例如組合、聚合、依賴等。可是隻有出如今成員變量、方法的輸入輸出參數中的類才稱爲成員朋友類，而出如今方法體內 部的類不屬於朋友類。注意 一個類只和朋友交流，不與陌生類交流，不要出現getA().getB().getC().getD()這種 狀況（在一種極端的狀況下容許出現這種訪問，即每個點號後面的返回類型都相同），類 與類之間的關係是創建在類間的，而不是方法間，所以一個方法儘可能不引入一個類中不存在 的對象，固然，JDK API提供的類除外。

• 朋友間也是有距離的：一個類公開的public屬性或方法越多，修改時涉及的面也就越大，變動引發的風險擴散 也就越大。所以，爲了保持朋友類間的距離，在設計時須要反覆衡量：是否還能夠再減小 public方法和屬性，是否能夠修改成private、package-private（包類型，在類、方法、變量前 不加訪問權限，則默認爲包類型）、protected等訪問權限，是否能夠加上final關鍵字等。 注意 迪米特法則要求類「羞澀」一點，儘可能不要對外公佈太多的public方法和非靜態的 public變量，儘可能內斂，多使用private、package-private、protected等訪問權限。

• 是本身的就是本身的：在實際應用中常常會出現這樣一個方法：放在本類中也能夠，放在其餘類中也沒有錯， 那怎麼去衡量呢？你能夠堅持這樣一個原則：若是一個方法放在本類中，既不增長類間關 系，也對本類不產生負面影響，那就放置在本類中。

• 謹慎使用Serializable：在實際應用中，這個問題是不多出現的，即便出現也會當即被發現並獲得解決。是怎麼 回事呢？舉個例子來講，在一個項目中使用RMI（Remote Method Invocation，遠程方法調 用）方式傳遞一個VO（Value Object，值對象），這個對象就必須實現Serializable接口（僅 僅是一個標誌性接口，不須要實現具體的方法），也就是把須要網絡傳輸的對象進行序列 化，不然就會出現NotSerializableException異常。忽然有一天，客戶端的VO修改了一個屬性 的訪問權限，從private變動爲public，訪問權限擴大了，若是服務器上沒有作出相應的變 更，就會報序列化失敗，就這麼簡單。可是這個問題的產生應該屬於項目管理範疇，一個類 或接口在客戶端已經變動了，而服務器端卻沒有同步更新，難道不是項目管理的失職嗎？

最佳實踐

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

不知道你們有沒有聽過這樣一個理論：「任何兩個素不相識的人中間最多隻隔着6我的， 即只經過6我的就能夠將他們聯繫在一塊兒」，這就是著名的「六度分隔理論」。若是將這個理論 應用到咱們的項目中，也就是說，我和我要調用的類之間最多有6次傳遞。呵呵，這隻能讓 你們當個樂子來看，在實際應用中，若是一個類跳轉兩次以上才能訪問到另外一個類，就須要 想辦法進行重構了，爲何是兩次以上呢？由於一個系統的成功不只僅是一個標準或是原則 就可以決定的，有很是多的外在因素決定，跳轉次數越多，系統越複雜，維護就越困難，所 以只要跳轉不超過兩次都是能夠忍受的，這須要具體問題具體分析。

迪米特法則要求類間解耦，但解耦是有限度的，除非是計算機的最小單元——二進制的 0和1。那纔是徹底解耦，在實際的項目中，須要適度地考慮這個原則，別爲了套用原則而作 項目。原則只是供參考，若是違背了這個原則，項目也未必會失敗，這就須要你們在採用原 則時反覆度量，不遵循是不對的，嚴格執行就是「過猶不及」。