設計模式之禅之六大設計原則-迪米特原則

迪米特法則

一：迪米特法則定義：

        ---->迪米特法則(Law of Demeter,LoD)也稱為最少知識原則(Least Knowledge

Principle,LKP),

        ---->一個對象應該對其他對象有最少的了解。通俗地講,一個類應該對自己需要耦合或調用的類知道得最少,你(被耦合或調用的類)的内部是如何複雜都和我沒關系,那是你的事情,我就知道你提供的這麼多public方法,我就調用這麼多,其他的我一概不關心。

二：迪米特法則對類的低耦合提出明确的要求。

        --->隻和朋友交流。【在業務場景中，盡量和少的朋友交流，降低耦合度】

              （1）迪米特法則還有一個英文解釋是:Only talk to your immediate friends(隻與直接的朋友通信。)什麼叫做直接的朋友呢?每個對象都必然會與其他對象有耦合關系,兩個對象之間的耦合就成為朋友關系,這種關系的類型有很多,例如組合、聚合、依賴等。下面我們将舉例說明如何才能做到隻與直接的朋友交流。

              （2）朋友類的定義是這樣的:出現在成員變量、方法的輸入輸出參數中的類稱為成員朋友類,而出現在方法體内部的類不屬于朋友類

              （3）一個類隻和朋友交流,不與陌生類交流,不要出現getA().getB().getC().getD()這種情況(在一種極端的情況下允許出現這種通路,即每一個點号後面的傳回類型都相同),類與類之間的關系是建立在類間的,而不是方法間,是以一個方法盡量不引入一個類中不存在的對象,當然,JDK API提供的類除外。

        --->朋友間也是有距離的。【要向依賴類提供盡量少的public方法】

               （1） 一個類公開的public屬性或方法越多,修改時涉及的面也就越大,變更引起的風險擴散也就越大。是以,為了保持朋友類間的距離,在設計時需要反複衡量:是否還可以再減少public方法和屬性,是否可以修改為private、package-private(包類型,在類、方法、變量前不加通路權限,則預設為包類型)、protected等通路權限,是否可以加上final關鍵字等。

               （2）迪米特法則要求類“羞澀”一點,盡量不要對外公布太多的public方法和非靜态的public變量,盡量内斂,多使用private、package-private、protected等通路權限。

        --->是自己的就是自己的

                （1）在實際應用中經常會出現這樣一個方法:放在本類中也可以,放在其他類中也沒有錯,那怎麼去衡量呢?你可以堅持這樣一個原則:如果一個方法放在本類中,既不增加類間關系,也對本類不産生負面影響,那就放置在本類中。

         --->謹慎使用Serializable

                  （1）在實際應用中,這個問題是很少出現的,即使出現也會立即被發現并得到解決。是怎麼回事呢?舉個例子來說,在一個項目中使用RMI(Remote Method Invocation,遠端方法調用)方式傳遞一個VO(Value Object,值對象),這個對象就必須實作Serializable接口(僅僅是一個标志性接口,不需要實作具體的方法),也就是把需要網絡傳輸的對象進行序列化,否則就會出現NotSerializableException異常。突然有一天,用戶端的VO修改了一個屬性的通路權限,從private變更為public,通路權限擴大了,如果伺服器上沒有做出相應的變更,就會報序列化失敗,就這麼簡單。

三，最佳實踐

        ---->迪米特法則的核心觀念就是類間解耦,弱耦合,隻有弱耦合了以後,類的複用率才可以提高。其要求的結果就是産生了大量的中轉或跳轉類,導緻系統的複雜性提高,同時也為維護帶來了難度。讀者在采用迪米特法則時需要反複權衡,既做到讓結構清晰,又做到高内聚低耦合。

        --->迪米特法則要求類間解耦,但解耦是有限度的,原則隻是供參考,如果違背了這個原則,項目也未必會失敗,這就需要大家在采用原則時反複度量,不遵循是不對的,嚴格執行就是“過猶不及”。

四：中心思想

        （1）一個場景中，A，B，C類。完成一個目标。A依賴B，B依賴C，不重複依賴（老師讓體育委員統計人員的場景），達到最少的類的交流。降低類類之間的耦合度

        （2）被依賴類給依賴類暴露最少的public方法和屬性。

        （3）一旦耦合度降低，則跳轉就多。則考慮原則情況下，也不能讓調用層過多。