概念
迪米特法則解決類與類之間耦合度問題，如果類A調用了B類的某一個方法，則這兩個類就形成了一種緊耦合的方式，當B類這個方法發生變化時，一定會影響A類的執行結果。迪米特法則要求每一個類盡可能少的與其他類發生關系，也就是盡可能少的讓其他類發生變化時，對其代碼的執行結果產生的影響降到最低。
典型情況：A類調用B類的方法，B類和C類是一種關聯關系，如果A類通過B類所持有的C類對象直接調用C類的方法，則A類和C類同時擁有強耦合的關系。代碼如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
public class B { public C c = new C();}public class C { public void fun() { //相關代碼 }}public class A { public void show(){ B b = new B(); b.c.fun(); }} |
這種調用A和C之間形成一種強耦合，當C中fun代碼發生變化時，一定會影響到A，不符合迪米特法則。按照迪米特法則的要求可修改為：
|
1
2
3
4
5
6
7
8
9
10
11
12
|
public class B { private C c = new C(); public void fun(){ c.fun(); }}public class A { public void show(){ B b = new B(); b.fun(); }} |
A和C代碼完全脫耦，當C的fun代碼發生變化時，只需要修改類B中fun代碼；當A中業務邏輯發生變化時，需要修改B中fun代碼，也只需修改B中代碼，和C中代碼無關。
迪米特法則又叫做最少知識原則(LKP),就是說,一個對象應當對其他對象有盡可能少的了解。通俗的講“不和陌生人講話，只和朋友交流”，上述示例中類A和類B是朋友，和類C是陌生人。
使用
迪米特法則解決了類之間耦合度問題，使得類與類之間的接口通訊變得簡單，提高了可維護性，但同時也增加了調用層次和復雜度。但以下情況一定要使用迪米特法則規避風險。
1.使用第三方組件或者控件時，增加一個包裝器的類，使得調用方和第三方組件完全脫耦，如桌面程序中使用XP style一組控件屬于第三方控件，每個控件增加一個包裝器類，無論什么時間，XP style控件不能使用時，如：免費突然變收費，我們只需要修改包裝器類中代碼即可。
2.對于預期會發生較大變化的模塊，增加一個外觀層，簡化和穩定高層模塊的調用關系，與不穩定部分脫耦。
3.對付團隊新成員或代碼質量較差程序員，增加一個外觀層，避免因頻繁的修改，造成整個程序掛掉。
拓展
1.意思就是降低各個對象之間的耦合，提高系統的可維護性；
2.迪米特法則是一種設計思想，不僅僅體現在對象與對象的之間的耦合度問題上，而是廣泛應用到各種分層結構中層與層之間的關系，每個層之間形成一種隔離關系，調用無需了解層內部及更下一級層的調用關系。如MVP模式，P將M和V結合起來，使得M和V都可以獨立的進行變化，任何一方的變化僅影響到P層代碼的變化。
3.前端開發時使用獨立出來的API就是迪米特法則的要求，如：
|
1
2
3
4
|
var api = { adminLogin: (param) => post(apiBase+"/sys/login", param), userLogin: (param) => post(apiBase+"/sys/weblogin", param), } |
頁面調用時只需要調用api中定義的adminLogin方法，當后端定義的路勁名apiBase、方法名login發生變化時，只修改api即可，不會影響到調用頁面的代碼
4. 設計模式中對象適配器、代理模式、門面模式等均體現了迪米特法則的思想。
以上就是java面向對象設計原則之迪米特法則分析詳解的詳細內容，更多關于java面向對象設計原則的資料請關注服務器之家其它相關文章！
原文鏈接：https://blog.csdn.net/guoyp2126/article/details/114074525
