迪米特法則（Law of Demeter，LoD）也稱(chēng)為最少知識(shí)原則（Least KnowledgePrinciple，LKP），雖然名字不同，但描述的是同一個(gè)規(guī)則：一個(gè)對(duì)象應(yīng)該對(duì)其他對(duì)象有最少的了解。通俗地講，一個(gè)類(lèi)應(yīng)該對(duì)自己需要耦合或調(diào)用的類(lèi)知道得最少，你（被耦合或調(diào)用的類(lèi)）的內(nèi)部是如何復(fù)雜都和我沒(méi)關(guān)系，那是你的事情，我就知道你提供的這么多public方法，我就調(diào)用這么多，其他的我一概不關(guān)心。

迪米特法則對(duì)類(lèi)的低耦合提出了明確的要求，其包含以下4層含義.

1.只和朋友交流

迪米特法則還有一個(gè)英文解釋是：Only talk to your immediate friends（只與直接的朋友通信。）什么叫做直接的朋友呢？每個(gè)對(duì)象都必然會(huì)與其他對(duì)象有耦合關(guān)系，兩個(gè)對(duì)象之間的耦合就成為朋友關(guān)系，這種關(guān)系的類(lèi)型有很多，例如組合、聚合、依賴(lài)等。下面我們將舉例說(shuō)明如何才能做到只與直接的朋友交流。

下面是老師讓體育委員確認(rèn)全班女生人數(shù)的例子:

Teacher類(lèi)的commond方法負(fù)責(zé)發(fā)送命令給體育會(huì)員，命令他清點(diǎn)女生，其實(shí)現(xiàn)過(guò)程如代碼如下所示:

public class Teacher {//老師對(duì)學(xué)生發(fā)布命令,清一下女生public void commond(GroupLeader groupLeader){List<Girl> listGirls = new ArrayList();//初始化女生for(int i=0;i<20;i++){listGirls.add(new Girl());}//告訴體育委員開(kāi)始執(zhí)行清查任務(wù) groupLeader.countGirls(listGirls);} }

老師只有一個(gè)方法commond，先定義出所有的女生，然后發(fā)布命令給體育委員，去清點(diǎn)一下女生的數(shù)量。體育委員GroupLeader的實(shí)現(xiàn)過(guò)程如代碼清單如下所示:

體育委員實(shí)現(xiàn)類(lèi):

public class GroupLeader {//有清查女生的工作public void countGirls(List<Girl> listGirls){System.out.println("女生數(shù)量是："+listGirls.size());} }

老師類(lèi)和體育委員類(lèi)都對(duì)女生類(lèi)產(chǎn)生依賴(lài)，而且女生類(lèi)不需要執(zhí)行任何動(dòng)作，因此定義一個(gè)空類(lèi)，其實(shí)現(xiàn)過(guò)程如代碼如下所示:

public class Girl {}

故事中的三個(gè)角色都已經(jīng)有了，再定義一個(gè)場(chǎng)景類(lèi)來(lái)描述這個(gè)故事，其實(shí)現(xiàn)過(guò)程如代碼如下所示:

public class Client {public static void main(String[] args) {Teacher teacher= new Teacher();//老師發(fā)布命令teacher.commond(new GroupLeader());}}

運(yùn)行結(jié)果:

女生數(shù)量是：20

體育委員按照老師的要求對(duì)女生進(jìn)行了清點(diǎn)，并得出了數(shù)量。我們回過(guò)頭來(lái)思考一下這個(gè)程序有什么問(wèn)題，首先確定Teacher類(lèi)有幾個(gè)朋友類(lèi)，它僅有一個(gè)朋友類(lèi)——GroupLeader。

為什么Girl不是朋友類(lèi)呢？Teacher也對(duì)它產(chǎn)生了依賴(lài)關(guān)系呀！朋友類(lèi)的定義是這樣的：出現(xiàn)在成員變量、方法的輸入輸出參數(shù)中的類(lèi)稱(chēng)為成員朋友類(lèi)，而出現(xiàn)在方法體內(nèi)部的類(lèi)不屬于朋友類(lèi)，而Girl這個(gè)類(lèi)就是出現(xiàn)在commond方法體內(nèi)，因此不屬于Teacher類(lèi)的朋友類(lèi)。迪米特法則告訴我們一個(gè)類(lèi)只和朋友類(lèi)交流，但是我們剛剛定義的commond方法卻與Girl類(lèi)有了交流，聲明了一個(gè)List<Girls>動(dòng)態(tài)數(shù)組，也就是與一個(gè)陌生的類(lèi)Girl有了交流，這樣就破壞了Teacher的健壯性。方法是類(lèi)的一個(gè)行為，類(lèi)竟然不知道自己的行為與其他類(lèi)產(chǎn)生依賴(lài)關(guān)系，這是不允許的，嚴(yán)重違反了迪米特法則。
問(wèn)題已經(jīng)發(fā)現(xiàn)，我們修改一下程序，將類(lèi)圖稍作修改，如下圖:

在類(lèi)圖中去掉Teacher對(duì)Girl類(lèi)的依賴(lài)關(guān)系，修改后的Teacher類(lèi)如代碼如下所示:

public class Teacher {//老師對(duì)學(xué)生發(fā)布命令,清一下女生public void commond(GroupLeader groupLeader){//告訴體育委員開(kāi)始執(zhí)行清查任務(wù) groupLeader.countGirls();} }

體育委員類(lèi):

public class GroupLeader {private List<Girl> listGirls;//傳遞全班的女生進(jìn)來(lái)public GroupLeader(List<Girl> _listGirls){this.listGirls = _listGirls;}//有清查女生的工作public void countGirls(){System.out.println("女生數(shù)量是："+this.listGirls.size());} }

在GroupLeader類(lèi)中定義了一個(gè)構(gòu)造函數(shù)，通過(guò)構(gòu)造函數(shù)傳遞了依賴(lài)關(guān)系。同時(shí)，對(duì)場(chǎng)景類(lèi)也進(jìn)行了一些修改，如代碼如下所示:

1 public class Client { 2 3 public static void main(String[] args) { 4 //產(chǎn)生一個(gè)女生群體 5 List<Girl> listGirls = new ArrayList<Girl>(); 6 //初始化女生 7 for(int i=0;i<20;i++){ 8 listGirls.add(new Girl()); 9 } 10 11 Teacher teacher= new Teacher(); 12 13 //老師發(fā)布命令 14 teacher.commond(new GroupLeader(listGirls)); 15 } 16 17 }

對(duì)程序進(jìn)行了簡(jiǎn)單的修改，把Teacher中對(duì)List<Girl>的初始化移動(dòng)到了場(chǎng)景類(lèi)中，同時(shí)在GroupLeader中增加了對(duì)Girl的注入，避開(kāi)了Teacher類(lèi)對(duì)陌生類(lèi)Girl的訪(fǎng)問(wèn)，降低了系統(tǒng)間的耦合，提高了系統(tǒng)的健壯性。

注意　一個(gè)類(lèi)只和朋友交流，不與陌生類(lèi)交流，不要出現(xiàn)getA().getB().getC().getD()這種情況（在一種極端的情況下允許出現(xiàn)這種訪(fǎng)問(wèn)，即每一個(gè)點(diǎn)號(hào)后面的返回類(lèi)型都相同），類(lèi)與類(lèi)之間的關(guān)系是建立在類(lèi)間的，而不是方法間，因此一個(gè)方法盡量不引入一個(gè)類(lèi)中不存在的對(duì)象，當(dāng)然，JDK API提供的類(lèi)除外。

2. 朋友間也是有距離的

人和人之間是有距離的，太遠(yuǎn)關(guān)系逐漸疏遠(yuǎn)，最終形同陌路；太近就相互刺傷。對(duì)朋友關(guān)系描述最貼切的故事就是：兩只刺猬取暖，太遠(yuǎn)取不到暖，太近刺傷了對(duì)方，必須保持一

個(gè)既能取暖又不刺傷對(duì)方的距離。迪米特法則就是對(duì)這個(gè)距離進(jìn)行描述，即使是朋友類(lèi)之間也不能無(wú)話(huà)不說(shuō)，無(wú)所不知。
我們?cè)诎惭b軟件的時(shí)候，經(jīng)常會(huì)有一個(gè)導(dǎo)向動(dòng)作，第一步是確認(rèn)是否安裝，第二步確認(rèn)License，再然后選擇安裝目錄……這是一個(gè)典型的順序執(zhí)行動(dòng)作，具體到程序中就是：調(diào)用
一個(gè)或多個(gè)類(lèi)，先執(zhí)行第一個(gè)方法，然后是第二個(gè)方法，根據(jù)返回結(jié)果再來(lái)看是否可以調(diào)用第三個(gè)方法，或者第四個(gè)方法，等等，其類(lèi)圖如下所示:

?

很簡(jiǎn)單的類(lèi)圖，實(shí)現(xiàn)軟件安裝的過(guò)程，其中first方法定義第一步做什么，second方法定義第二步做什么，third方法定義第三步做什么，其實(shí)現(xiàn)過(guò)程如代碼清單如下所示:

1 public class Wizard { 2 private Random rand = new Random(System.currentTimeMillis()); 3 //第一步 4 public int first(){ 5 System.out.println("執(zhí)行第一個(gè)方法..."); 6 return rand.nextInt(100); 7 } 8 9 //第二步 10 public int second(){ 11 System.out.println("執(zhí)行第二個(gè)方法..."); 12 return rand.nextInt(100); 13 } 14 15 //第三個(gè)方法 16 public int third(){ 17 System.out.println("執(zhí)行第三個(gè)方法..."); 18 return rand.nextInt(100); 19 } 20 21 22 }

?

?在Wizard類(lèi)中分別定義了三個(gè)步驟方法，每個(gè)步驟中都有相關(guān)的業(yè)務(wù)邏輯完成指定的任務(wù)，我們使用一個(gè)隨機(jī)函數(shù)來(lái)代替業(yè)務(wù)執(zhí)行的返回值。軟件安裝InstallSoftware類(lèi)如代碼清單

?如下所示:

1 public class InstallSoftware { 2 3 public void installWizard(Wizard wizard){ 4 int first = wizard.first(); 5 //根據(jù)first返回的結(jié)果，看是否需要執(zhí)行second 6 if(first>50){ 7 int second = wizard.second(); 8 if(second>50){ 9 int third = wizard.third(); 10 if(third >50){ 11 wizard.first(); 12 } 13 } 14 } 15 16 } 17 }

?

根據(jù)每個(gè)方法執(zhí)行的結(jié)果決定是否繼續(xù)執(zhí)行下一個(gè)方法，模擬人工的選擇操作。場(chǎng)景類(lèi)如代碼清單如下所示:

場(chǎng)景類(lèi):

public class Client {public static void main(String[] args) {InstallSoftware invoker = new InstallSoftware();invoker.installWizard(new Wizard());} }

?

以上程序很簡(jiǎn)單，運(yùn)行結(jié)果和隨機(jī)數(shù)有關(guān)，每次的執(zhí)行結(jié)果都不相同，需要讀者自己運(yùn)行并查看結(jié)果。程序雖然簡(jiǎn)單，但是隱藏的問(wèn)題可不簡(jiǎn)單，思考一下程序有什么問(wèn)題。
Wizard類(lèi)把太多的方法暴露給InstallSoftware類(lèi)，兩者的朋友關(guān)系太親密了，耦合關(guān)系變得異常牢固。如果要將Wizard類(lèi)中的first方法返回值的類(lèi)型由int改為boolean，就需要修改InstallSoftware類(lèi)，從而把修改變更的風(fēng)險(xiǎn)擴(kuò)散開(kāi)了。因此，這樣的耦合是極度不合適的，我們需要對(duì)設(shè)計(jì)進(jìn)行重構(gòu)，重構(gòu)后的類(lèi)圖如下圖所示:

?

在Wizard類(lèi)中增加一個(gè)installWizard方法，對(duì)安裝過(guò)程進(jìn)行封裝，同時(shí)把原有的三個(gè)public方法修改為private方法，如代碼清單如下所示:

修改后的導(dǎo)向類(lèi)實(shí)現(xiàn)過(guò)程

1 public class Wizard { 2 private Random rand = new Random(System.currentTimeMillis()); 3 //第一步 4 private int first(){ 5 System.out.println("執(zhí)行第一個(gè)方法..."); 6 return rand.nextInt(100); 7 } 8 9 //第二步 10 private int second(){ 11 System.out.println("執(zhí)行第二個(gè)方法..."); 12 return rand.nextInt(100); 13 } 14 15 //第三個(gè)方法 16 private int third(){ 17 System.out.println("執(zhí)行第三個(gè)方法..."); 18 return rand.nextInt(100); 19 } 20 21 //軟件安裝過(guò)程 22 public void installWizard(){ 23 int first = this.first(); 24 //根據(jù)first返回的結(jié)果，看是否需要執(zhí)行second 25 if(first>50){ 26 int second = this.second(); 27 if(second>50){ 28 int third = this.third(); 29 if(third >50){ 30 this.first(); 31 } 32 } 33 } 34 35 } 36 }

?

將三個(gè)步驟的訪(fǎng)問(wèn)權(quán)限修改為private，同時(shí)把InstallSoftware中的方法installWizad移動(dòng)到Wizard方法中。通過(guò)這樣的重構(gòu)后，Wizard類(lèi)就只對(duì)外公布了一個(gè)public方法，即使要修改first方法的返回值，影響的也僅僅只是Wizard本身，其他類(lèi)不受影響，這顯示了類(lèi)的高內(nèi)聚特性。

對(duì)InstallSoftware類(lèi)進(jìn)行少量的修改，如代碼清單如下所示:

public class InstallSoftware {public void installWizard(Wizard wizard){//不廢話(huà)，直接調(diào)用 wizard.installWizard();}void abc(){} }

場(chǎng)景類(lèi)Client沒(méi)有任何改變，如代碼清單5-10所示。通過(guò)進(jìn)行重構(gòu)，類(lèi)間的耦合關(guān)系變?nèi)趿?#xff0c;結(jié)構(gòu)也清晰了，變更引起的風(fēng)險(xiǎn)也變小了。
一個(gè)類(lèi)公開(kāi)的public屬性或方法越多，修改時(shí)涉及的面也就越大，變更引起的風(fēng)險(xiǎn)擴(kuò)散也就越大。

因此，為了保持朋友類(lèi)間的距離，在設(shè)計(jì)時(shí)需要反復(fù)衡量：是否還可以再減少public方法和屬性，是否可以修改為private、package-private（包類(lèi)型，在類(lèi)、方法、變量前
不加訪(fǎng)問(wèn)權(quán)限，則默認(rèn)為包類(lèi)型）、protected等訪(fǎng)問(wèn)權(quán)限，是否可以加上final關(guān)鍵字等。

注意　迪米特法則要求類(lèi)“羞澀”一點(diǎn)，盡量不要對(duì)外公布太多的public方法和非靜態(tài)的public變量，盡量?jī)?nèi)斂，多使用private、package-private、protected等訪(fǎng)問(wèn)權(quán)限。

3. 是自己的就是自己的

?在實(shí)際應(yīng)用中經(jīng)常會(huì)出現(xiàn)這樣一個(gè)方法：放在本類(lèi)中也可以，放在其他類(lèi)中也沒(méi)有錯(cuò)，那怎么去衡量呢？你可以堅(jiān)持這樣一個(gè)原則：如果一個(gè)方法放在本類(lèi)中，既不增加類(lèi)間關(guān)

系，也對(duì)本類(lèi)不產(chǎn)生負(fù)面影響，那就放置在本類(lèi)中。

4. 謹(jǐn)慎使用Serializable

?

在實(shí)際應(yīng)用中，這個(gè)問(wèn)題是很少出現(xiàn)的，即使出現(xiàn)也會(huì)立即被發(fā)現(xiàn)并得到解決。是怎么回事呢？舉個(gè)例子來(lái)說(shuō)，在一個(gè)項(xiàng)目中使用RMI（Remote Method Invocation，遠(yuǎn)程方法調(diào)
用）方式傳遞一個(gè)VO（Value Object，值對(duì)象），這個(gè)對(duì)象就必須實(shí)現(xiàn)Serializable接口（僅僅是一個(gè)標(biāo)志性接口，不需要實(shí)現(xiàn)具體的方法），也就是把需要網(wǎng)絡(luò)傳輸?shù)膶?duì)象進(jìn)行序列化，否則就會(huì)出現(xiàn)NotSerializableException異常。突然有一天，客戶(hù)端的VO修改了一個(gè)屬性的訪(fǎng)問(wèn)權(quán)限，從private變更為public，訪(fǎng)問(wèn)權(quán)限擴(kuò)大了，如果服務(wù)器上沒(méi)有做出相應(yīng)的變更，就會(huì)報(bào)序列化失敗，就這么簡(jiǎn)單。但是這個(gè)問(wèn)題的產(chǎn)生應(yīng)該屬于項(xiàng)目管理范疇，一個(gè)類(lèi)或接口在客戶(hù)端已經(jīng)變更了，而服務(wù)器端卻沒(méi)有同步更新，難道不是項(xiàng)目管理的失職嗎？

?

?

?最佳實(shí)踐?

迪米特法則的核心觀(guān)念就是類(lèi)間解耦，弱耦合，只有弱耦合了以后，類(lèi)的復(fù)用率才可以提高。其要求的結(jié)果就是產(chǎn)生了大量的中轉(zhuǎn)或跳轉(zhuǎn)類(lèi)，導(dǎo)致系統(tǒng)的復(fù)雜性提高，同時(shí)也為維
護(hù)帶來(lái)了難度。讀者在采用迪米特法則時(shí)需要反復(fù)權(quán)衡，既做到讓結(jié)構(gòu)清晰，又做到高內(nèi)聚低耦合。
不知道大家有沒(méi)有聽(tīng)過(guò)這樣一個(gè)理論：“任何兩個(gè)素不相識(shí)的人中間最多只隔著6個(gè)人，即只通過(guò)6個(gè)人就可以將他們聯(lián)系在一起”，這就是著名的“六度分隔理論”。如果將這個(gè)理論
應(yīng)用到我們的項(xiàng)目中，也就是說(shuō)，我和我要調(diào)用的類(lèi)之間最多有6次傳遞。呵呵，這只能讓大家當(dāng)個(gè)樂(lè)子來(lái)看，在實(shí)際應(yīng)用中，如果一個(gè)類(lèi)跳轉(zhuǎn)兩次以上才能訪(fǎng)問(wèn)到另一個(gè)類(lèi)，就需要
想辦法進(jìn)行重構(gòu)了，為什么是兩次以上呢？因?yàn)橐粋€(gè)系統(tǒng)的成功不僅僅是一個(gè)標(biāo)準(zhǔn)或是原則就能夠決定的，有非常多的外在因素決定，跳轉(zhuǎn)次數(shù)越多，系統(tǒng)越復(fù)雜，維護(hù)就越困難，所
以只要跳轉(zhuǎn)不超過(guò)兩次都是可以忍受的，這需要具體問(wèn)題具體分析。
迪米特法則要求類(lèi)間解耦，但解耦是有限度的，除非是計(jì)算機(jī)的最小單元——二進(jìn)制的0和1。那才是完全解耦，在實(shí)際的項(xiàng)目中，需要適度地考慮這個(gè)原則，別為了套用原則而做
項(xiàng)目。原則只是供參考，如果違背了這個(gè)原則，項(xiàng)目也未必會(huì)失敗，這就需要大家在采用原則時(shí)反復(fù)度量，不遵循是不對(duì)的，嚴(yán)格執(zhí)行就是“過(guò)猶不及”。

?

總結(jié)

以上是生活随笔為你收集整理的[设计模式]设计模式之禅关于迪米特法则的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。