法則定義
迪米特法則（Law of Demeter）又叫作最少知識原則（Least Knowledge Principle 簡寫LKP），就是說一個對象應當對其他對象有儘可能少的瞭解,不和陌生人說話。英文簡寫爲: LoD.
來源歷史
1987年秋天由美國Northeastern University的Ian Holland提出，被UML的創始者之一Booch等普及。後來，因爲在經典著作《 The Pragmatic Programmer》而廣爲人知。
模式與意義
迪米特法則可以簡單說成：talk only to your immediate friends。 對於面向OOD來說，又被解釋爲下面幾種方式：一個軟件實體應當儘可能少的與其他實體發生相互作用。每一個軟件單位對其他的單位都只有最少的知識，而且局 限於那些與本單位密切相關的軟件單位。 迪米特法則的初衷在於降低類之間的耦合。由於每個類儘量減少對其他類的依賴，因此，很容易使得 系統的功能模塊功能獨立，相互之間不存在（或很少有）依賴關係。 迪米特法則不希望類直接建立直接的接觸。如果真的有需要建立聯繫，也希望能通過它的友元類來轉 達。因此，應用迪米特法則有可能造成的一個後果就是：系統中存在大量的中介類，這些類之所以存在完全是爲了傳遞類之間的相互調用關係——這在一定程度上增 加了系統的複雜度。 有興趣可以研究一下設計模式的門面模式（Facade）和中介模式（Mediator），都是 迪米特法則應用的例子。 值得一提的是，雖然Ian Holland對計算機科學的貢獻也僅限於這一條法則，其他方面的建樹不多，但是，這一法則卻不僅僅侷限於計算機領域，在其他領域也同樣適用。比如，美國 人就在航天系統的設計中採用這一法則。
缺點
補充： 狹義的迪米特法則的缺點： 在系統裏造出大量的小方法，這些方法僅僅是傳遞間接的調用，與系統的商務邏輯無關。 遵循類之間的迪米特法則會是一個系統的局部設計簡化，因爲每一個局部都不會和遠距離的對象有直 接的關聯。但是，這也會造成系統的不同模塊之間的通信效率降低，也會使系統的不同模塊之間不容易協調。 門面模式和調停者模式實際上就是迪米特法則的應用。 廣義的迪米特法則在類的設計上的體現： 優先考慮將一個類設置成不變類。 儘量降低一個類的訪問權限。 謹慎使用Serializable。 儘量降低成員的訪問權限。
在《投名狀》這部轟動一時的影片中有這麼一個片段，慈禧太后召見龐青龍，帶路的太監說，從門口到見到老佛爺（也就是慈禧太后）這條短短的路他花了大半輩子 才走完，而很多人一輩子也走不完，感嘆道：“你倒好，這麼短的時間裏就走了別人花費一生才能走完的道路”。
定義：
迪米特法則(Law of Demeter，簡寫LoD )又叫做最少知識原則（LeastKnowledge Principle 簡寫LKP），也就是說，一個對象應當對其他對象儘可能少的瞭解，不和陌生人說話。
迪米特法則最初是用來作爲面向對象的系統設計風格的一種法則，於1987年秋天由lanholland在美國東北大學爲一個叫做迪米特的項目設計提出的。 被UML的創始者之一Booch等普及。後來，因爲在經典著作《 The PragmaticProgrammer》闡述而廣爲人知。
狹義的迪米特法則是指：如果兩個類不必彼此直接通信，那麼這兩個類就不應當發生直接的相互作用。如果其中一個類需要調用另一類的某一個方法的話，可 以通過第三者轉發這個調用。
廣義的迪米特法則是指：一個模塊設計的好壞的一個重要標誌就是該模塊在多大程度上講自己的內部數據與實現的有關細節隱藏起來。
一個軟件實體應當儘可能少的與其他實體發生相互作用。
每一個軟件單位對其他的單位都只有最少的知識，而且侷限於那些與本單位密切相關的軟件單位。
迪米特法則的目的在於降低類與類之間的耦合。由於每個類儘量減少對其他類的依賴，因此，很容易使得系統的功能模塊功能獨立，是的相互間存在儘可能少 的依賴關係。
在運用迪米特法則到系統的設計中時,要注意以下幾點:
第一：在類的劃分上，應當創建弱耦合的類，類與類之間的耦合越弱，就越有利於實現可複用的目標。
第二：在類的結構設計上，每個類都應該降低成員的訪問權限。
第三：在類的設計上，只要有可能，一個類應當設計成不變的類。
第四：在對其他類的應用上，一個對象對其他類的對象的應用應該降到最低。
第五：儘量限制局部變量的有效範圍。
但是過度使用迪米特法則，也會造成系統的不同模塊之間的通信效率降低，使系統的不同模塊之間不容易協調等缺點。同時，因爲迪米特法則要求類與類之間 儘量不直接通信，如果類之間需要通信就通過第三方轉發的方式，這就直接導致了系統中存在大量的中介類，這些類存在的唯一原因是爲了傳遞類與類之間的相互調 用關係，這就毫無疑問的增加了系統的複雜度。解決這個問題的方式是：使用依賴倒轉原則（通俗的講就是要針對接口編程，不要針對具體編程），這要就可以是調 用方和被調用方之間有了一個抽象層，被調用方在遵循抽象層的前提下就可以自由的變化，此時抽象層成了調用方的朋友。
如下圖所示：
故事分析：
慈禧太后要召見龐青龍。龐青龍在見到慈禧太后前經歷了那些過程呢？首先，當然是有人通知龐青龍要被召見，通知龐青龍的人當然不會是慈禧本人！慈禧只是下達 旨意，然後又相關的只能部門傳達旨意，相關部門的領導人也不會親自去通知龐青龍，這些領導人會派遣信得過的人去，而這個被派遣的人也不是說想見龐青龍就能 見得了的，他也必須通過和龐青龍熟悉的人，最後才能見到龐青龍，從而才能成功的傳達旨意；第二：在進宮前，龐青龍必須卸掉自己隨身攜帶的任何武器；第三： 會有專門的只能部門對龐青龍進行全身徹底的檢查，以防有任何可以傷害人的東西攜帶在身上，當然這個過程可能非常的複雜和繁瑣。最後，由一個太監帶路到慈禧 面前。當然，見到慈禧的時候，龐青龍不是和慈禧坐在一起的，要報仇距離！慈禧也深深的懂得保持距離的重要性！
見到慈禧太后以後慈禧也沒有和龐青龍直接說話，因爲慈禧不和陌生人說話！而是同時身邊的人傳達自己的話，慈禧只需頤指氣使即可。
從上面的過程中我們可以看出處處體現了迪米特法則的應用，慈禧知道龐青龍這個人肯定是通過一層又一層的關係得知的，就是迪米特法則中的第三者轉發而且這裏 面說不定還有若干個第三者的轉發！而從慈溪下旨召見龐青龍到龐青龍收到旨意，這中間又是完美的提現了迪米特法則，這中間經歷無數的第三者！就連龐青龍面見 到慈禧後，慈禧也不和他直接說話，而是通過身邊的人傳話，這慈禧是不是太傻了，直接和他說不就行了嗎?慈禧當然不傻，因爲她深知迪米特法則的重要。兩個類 的對象之間如果不發生直接的聯繫就不直接發生關係！
不過這也產生了一個問題，這中間經歷這麼多的轉發，需要機構和人啊？或許這就是爲什麼當時的清政府機構那麼龐大、財政開支驚人的原因之一吧^_^
