迪米特法則

1987年秋天由美國Northeastern University的Ian Holland提出，被UML的創始者之一Booch等普及。後來，因為在經典著作《 The Pragmatic Programmer》而廣為人知。

迪米特法則可以簡單說成： talk only to your immediate friends。對於OOD來說，又被解釋為下面幾種方式：一個軟體實體應當儘可能少的與其他實體發生相互作用。每一個軟體單位對其他的單位都只有最少的知識，而且局限於那些與本單位密切相關的軟體單位。

迪米特法則的初衷在於降低類之間的耦合。由於每個類盡量減少對其他類的依賴，因此，很容易使得系統的功能模塊功能獨立，相互之間不存在（或很少有）依賴關係。

迪米特法則不希望類之間建立直接的聯繫。如果真的有需要建立聯繫，也希望能通過它的友元類來轉達。因此，應用迪米特法則有可能造成的一個後果就是：系統中存在大量的中介類，這些類之所以存在完全是為了傳遞類之間的相互調用關係——這在一定程度上增加了系統的複雜度。

有興趣可以研究一下設計模式的門面模式（Facade）和中介模式（Mediator），都是迪米特法則應用的例子。

值得一提的是，雖然Ian Holland對計算機科學的貢獻也僅限於這一條法則，其他方面的建樹不多，但是，這一法則卻不僅僅局限於計算機領域，在其他領域也同樣適用。比如，美國人就在航天系統的設計中採用這一法則。

狹義的迪米特法則

如果兩個類不必彼此直接通信，那麼這兩個類就不應當發生直接的相互作用。如果其中的一個類需要調用另一個類的某一個方法的話，可以通過第三者轉發這個調用。

朋友圈的確定

“朋友”條件：

1）當前對象本身（this）

2）以參量形式傳入到當前對象方法中的對象

3）當前對象的實例變數直接引用的對象

4）當前對象的實例變數如果是一個聚集，那麼聚集中的元素也都是朋友

5）當前對象所創建的對象

任何一個對象，如果滿足上面的條件之一，就是當前對象的“朋友”；否則就是“陌生人”。

狹義的迪米特法則的缺點：

在系統里造出大量的小方法，這些方法僅僅是傳遞間接的調用，與系統的業務邏輯無關。

遵循類之間的迪米特法則會是一個系統的局部設計簡化，因為每一個局部都不會和遠距離的對象有直接的關聯。但是，這也會造成系統的不同模塊之間的通信效率降低，也會使系統的不同模塊之間不容易協調。

門面模式和調停者模式（中介者模式）實際上就是迪米特法則的應用。

廣義的迪米特法則在類的設計上的體現：

優先考慮將一個類設置成不變類。

盡量降低一個類的訪問許可權。

謹慎使用Serializable。

盡量降低成員的訪問許可權。