定義：
（1）一個對象應該對其他對象保持最少的了解。又叫最少知道原則
（2）盡量降低類與類之間的耦合
（3）強調只和朋友交流，不和陌生人說話（意思就是對外部引入的類越少越好）。
朋友：指的是出現在成員變量，方法的輸入，輸出參數中的類稱為成員朋友類，而出現在方法體內部的類則不屬于朋友類。

優點：
降低類之間的耦合

如果過分的使用迪米特原則會產生大量的中介類，導致系統變復雜，為維護帶來難度，所以我們在使用迪米特的時候應該反復權衡，既要結構清晰，又要做到低耦合，高內聚 。
比如在我們開發中遇到一個這樣的情況，有這么一個方法，我們可以把它放到A類，也可以把它放到B類，那這種情況應該怎么做呢？
我們可以堅持一個原則：如果一個方法放到本類中，既不增加類間關系，也對本類不產生負面影響，我們就可以放到本類中。

以下通過案例進行理解迪米特原則：
那我們現在有這么一個場景：有一個課程網的大老板在這一天對一個Team說查一下到現在為止線上有多少個課程，那這里面呢關系到的類Boss，TeamLeader還有課程Course。

創建TeamLeader類，里面有個checkNumberOfCourses方法，參數是課程的集合，輸出課程的數量

創建Boss類，有一個查課程數量的方法，參數是TeamLeader，意思是叫TeamLeader查一下課程的數量

然后寫一個測試類Test

這樣案例就演示完了，我們分析一下看有沒有可以優化改進的地方。
我們看Boss中的方法

迪米特原則是只和直接的朋友交流，而在這個方法中，teamLeader作為入參，它是直接的朋友，朋友的定義就是直接出現在類成員變量里，而方法體內部的類不算朋友，例如Course這個類就不是Boss的朋友，Boss直接給TeamLeader下指令，TeamLeader直接把結果給Boss就可以了，Boss不需要關注Course這個類，不應該和Course交流，那目前的這種寫法就違背了迪米特原則

類圖如下：

如上圖所示Course這個類應該是由TeamLeader創建的而不是由Boss創建，所以我們現在應該修改一下實現，修改Boss和TeamLeader類


修改之后可以清晰的看出Boss類給TeamLeader類下指令，TeamLeader類直接查，Boss不需要了解課程類，然后TeamLeader類去跟Course類發生接觸。
類圖如下：

Course是由TeamLeader生成的，不再與Boss發生接觸，Boss也不需要知道Course。

對于迪米特原則，主要的是要可以分清楚那些是類的朋友，哪些不是。

總結

以上是生活随笔為你收集整理的java设计模式之设计原则⑤迪米特原则的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。