迪公尺特法則
一：迪公尺特法則定義：
---->迪公尺特法則(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）一旦耦合度降低，則跳轉就多。則考慮原則情況下，也不能讓呼叫層過多。
六大設計原則之迪公尺特原則
乙個餐廳中的顧客，點餐，點餐後的各種服務，買單等都是通過服務員 waiter 去完成的，public class customer public void myservice 服務員成了顧客和廚師以及餐廳其他人工作人員的樞紐 public class waiter public void orter...
六大設計原則之迪公尺特法則
定義 乙個類和另乙個類應該保持最小的了解 問題由來 類與類之間的關係越密切，耦合度越大，當乙個類發生變化時，對另乙個類影響也越大。解決方案 盡量降低類與類之間的耦合。總公司員工 class employee public string getid 分公司員工 class subemployee pu...
六大設計原則 迪公尺特原則
1 開閉原則 2 介面隔離原則 3 依賴倒置原則 4 迪公尺特原則 5 黎克特制替換原則 6 單一職責原則 乙個物件應該對其他物件保持最少的了解。物件導向語言是萬物皆物件，類與類之間互動越頻繁，類與類之間的關係也就越密切，這就是耦合，耦合度越高，當乙個類發生改變時，對另乙個類的影響也就越大。乙個好的...