5.2 我的知識你知道得越少越好 迪米特法則對類的低耦合提出了明確的要求，其包含以下4層含義。 1. 只和朋友交流 迪米特法則還有一個英文解釋是：Only talk to your immediate friends（只與直接的朋友通信。）什么叫做直接的朋友呢？每個對象都必然會與其他對象有耦合關系，兩個對象之間的耦合就成為朋友關系，這種關系的類型有很多，例如組合、聚合、依賴等。下面我們將舉例說明如何才能做到只與直接的朋友交流。 傳說中有這樣一個故事，老師想讓體育委員確認一下全班女生來齊沒有，就對他說：“你去把全班女生清一下。”體育委員沒聽清楚，就問道：“呀，……那親哪個？”老師無語了，我們來看這個笑話怎么用程序來實現，類圖如圖5-1所示。  圖5-1 老師要求清點女生類圖 Teacher類的commond方法負責發送命令給體育會員，命令他清點女生，其實現過程如代碼清單5-1所示。 代碼清單5-1 老師類 public?class?Teacher?{????? ?????//老師對學生發布命令，清一下女生 ?????public?void?commond(GroupLeader?groupLeader){ ?????????????List?listGirls?=?new?ArrayList(); ?????????????//初始化女生 ?????????????for(int?i=0;i<20;i++){ ?????????????????????listGirls.add(new?Girl()); ?????????????} ?????????????//告訴體育委員開始執行清查任務 ?????????????groupLeader.countGirls(listGirls); ?????} } 老師只有一個方法commond，先定義出所有的女生，然后發布命令給體育委員，去清點一下女生的數量。體育委員GroupLeader的實現過程如代碼清單5-2所示。 代碼清單5-2 體育委員類實現過程 public?class?GroupLeader?{? ?????//清查女生數量 ?????public?void?countGirls(List<Girl>?listGirls){ ?????????????System.out.println("女生數量是："+listGirls.size()); ?????} } 老師類和體育委員類都對女生類產生依賴，而且女生類不需要執行任何動作，因此定義一個空類，其實現過程如代碼清單5-3所示。 代碼清單5-3 女生類 public?class?Girl?{ } 故事中的三個角色都已經有了，再定義一個場景類來描述這個故事，其實現過程如代碼清單5-4所示。 代碼清單5-4 場景類 public?class?Client?{ ?????public?static?void?main(String[]?args)?{ ?????????????Teacher?teacher=?new?Teacher();???????????? ?????????????//老師發布命令 ?????????????teacher.commond(new?GroupLeader()); ?????} } 運行結果如下所示： 女生數量是：20 體育委員按照老師的要求對女生進行了清點，并得出了數量。我們回過頭來思考一下這個程序有什么問題，首先確定Teacher類有幾個朋友類，它僅有一個朋友類——GroupLeader。為什么Girl不是朋友類呢？Teacher也對它產生了依賴關系呀！朋友類的定義是這樣的：出現在成員變量、方法的輸入輸出參數中的類稱為成員朋友類，而出現在方法體內部的類不屬于朋友類，而Girl這個類就是出現在commond方法體內，因此不屬于Teacher類的朋友類。迪米特法則告訴我們一個類只和朋友類交流，但是我們剛剛定義的commond方法卻與Girl類有了交流，聲明了一個List<Girls>動態數組，也就是與一個陌生的類Girl有了交流，這樣就破壞了Teacher的健壯性。方法是類的一個行為，類竟然不知道自己的行為與其他類產生依賴關系，這是不允許的，嚴重違反了迪米特法則。 問題已經發現，我們修改一下程序，將類圖稍作修改，如圖5-2所示。  圖5-2 修改后的類圖 在類圖中去掉Teacher對Girl類的依賴關系，修改后的Teacher類如代碼清單5-5所示。 代碼清單5-5 修改后的老師類 public?class?Teacher?{ ?????//老師對學生發布命令，清一下女生 ?????public?void?commond(GroupLeader?groupLeader){ ?????????????//告訴體育委員開始執行清查任務 ?????????????groupLeader.countGirls(); ?????} } 修改后的GroupLeader類如代碼清代5-6所示。 代碼清單5-6 修改后的體育委員類 public?class?GroupLeader?{ ?????private?List<Girl>?listGirls; ?????//傳遞全班的女生進來 ?????public?GroupLeader(List<Girl>?_listGirls){ ?????????????this.listGirls?=?_listGirls; ?????}?? ?????//清查女生數量 ?????public?void?countGirls(){ ?????????????System.out.println("女生數量是："+this.listGirls.size()); ?????} } 在GroupLeader類中定義了一個構造函數，通過構造函數傳遞了依賴關系。同時，對場景類也進行了一些修改，如代碼清單5-7所示。 代碼清單5-7 修改后的場景類 public?class?Client?{ ?????public?static?void?main(String[]?args)?{ ?????????????//產生一個女生群體 ?????????????List<Girl>?listGirls?=?new?ArrayList<Girl>(); ?????????????//初始化女生 ?????????????for(int?i=0;i<20;i++){ ?????????????????????listGirls.add(new?Girl()); ?????????????}?????????????????? ?????????????Teacher?teacher=?new?Teacher();???????????? ?????????????//老師發布命令 ?????????????teacher.commond(new?GroupLeader(listGirls)); ?????}?? } 對程序進行了簡單的修改，把Teacher中對List<Girl>的初始化移動到了場景類中，同時在GroupLeader中增加了對Girl的注入，避開了Teacher類對陌生類Girl的訪問，降低了系統間的耦合，提高了系統的健壯性。 注意　一個類只和朋友交流，不與陌生類交流，不要出現getA().getB().getC().getD()這種情況（在一種極端的情況下允許出現這種訪問，即每一個點號后面的返回類型都相同），類與類之間的關系是建立在類間的，而不是方法間，因此一個方法盡量不引入一個類中不存在的對象，當然，JDK API提供的類除外。 2. 朋友間也是有距離的 人和人之間是有距離的，太遠關系逐漸疏遠，最終形同陌路；太近就相互刺傷。對朋友關系描述最貼切的故事就是：兩只刺猬取暖，太遠取不到暖，太近刺傷了對方，必須保持一個既能取暖又不刺傷對方的距離。迪米特法則就是對這個距離進行描述，即使是朋友類之間也不能無話不說，無所不知。 我們在安裝軟件的時候，經常會有一個導向動作，第一步是確認是否安裝，第二步確認License，再然后選擇安裝目錄……這是一個典型的順序執行動作，具體到程序中就是：調用一個或多個類，先執行第一個方法，然后是第二個方法，根據返回結果再來看是否可以調用第三個方法，或者第四個方法，等等，其類圖如圖5-3所示。  圖5-3 軟件安裝過程類圖 很簡單的類圖，實現軟件安裝的過程，其中first方法定義第一步做什么，second方法定義第二步做什么，third方法定義第三步做什么，其實現過程如代碼清單5-8所示。 代碼清單5-8 導向類 public?class?Wizard?{ ?????private?Random?rand?=?new?Random(System.currentTimeMillis()); ?????//第一步 ?????public?int?first(){ ?????????????System.out.println("執行第一個方法..."); ?????????????return?rand.nextInt(100); ?????}?? ?????//第二步 ?????public?int?second(){ ?????????????System.out.println("執行第二個方法..."); ?????????????return?rand.nextInt(100); ?????}?? ?????//第三個方法 ?????public?int?third(){ ?????????????System.out.println("執行第三個方法..."); ?????????????return?rand.nextInt(100); ?????} } 在Wizard類中分別定義了三個步驟方法，每個步驟中都有相關的業務邏輯完成指定的任務，我們使用一個隨機函數來代替業務執行的返回值。軟件安裝InstallSoftware類如代碼清單5-9所示。 代碼清單5-9 InstallSoftware類 public?class?InstallSoftware?{????? ?????public?void?installWizard(Wizard?wizard){ ?????????????int?first?=?wizard.first();?? ?????????????//根據first返回的結果，看是否需要執行second ?????????????if(first>50){ ??????????????????????int?second?=?wizard.second(); ??????????????????????if(second>50){ ????????????????????????????????int?third?=?wizard.third(); ????????????????????????????????if(third?>50){ ??????????????????????????????????????????wizard.first(); ??????????????????????} ?????????????????} ????????????}??????????? ?????} } 根據每個方法執行的結果決定是否繼續執行下一個方法，模擬人工的選擇操作。場景類如代碼清單5-10所示。 代碼清單5-10 場景類 public?class?Client?{?????? ?????public?static?void?main(String[]?args)?{ ?????????????InstallSoftware?invoker?=?new?InstallSoftware(); ?????????????invoker.installWizard(new?Wizard()); ?????} } 以上程序很簡單，運行結果和隨機數有關，每次的執行結果都不相同，需要讀者自己運行并查看結果。程序雖然簡單，但是隱藏的問題可不簡單，思考一下程序有什么問題。Wizard類把太多的方法暴露給InstallSoftware類，兩者的朋友關系太親密了，耦合關系變得異常牢固。如果要將Wizard類中的first方法返回值的類型由int改為boolean，就需要修改InstallSoftware類，從而把修改變更的風險擴散開了。因此，這樣的耦合是極度不合適的，我們需要對設計進行重構，重構后的類圖如圖5-4所示。  圖5-4 重構后的軟件安裝過程類圖 在Wizard類中增加一個installWizard方法，對安裝過程進行封裝，同時把原有的三個public方法修改為private方法，如代碼清單5-11所示。 代碼清單5-11 修改后的導向類實現過程 public?class?Wizard?{ ?????private?Random?rand?=?new?Random(System.currentTimeMillis()); ?????//第一步 ?????private?int?first(){ ?????????????System.out.println("執行第一個方法..."); ?????????????return?rand.nextInt(100); ?????}?? ?????//第二步 ?????private?int?second(){ ?????????????System.out.println("執行第二個方法..."); ?????????????return?rand.nextInt(100); ?????}?? ?????//第三個方法 ?????private?int?third(){ ?????????????System.out.println("執行第三個方法..."); ?????????????return?rand.nextInt(100); ?????}?? ?????//軟件安裝過程??? ?????public?void?installWizard(){??????????????? ?????????????int?first?=?this.first();?? ?????????????//根據first返回的結果，看是否需要執行second ?????????????if(first>50){ ??????????????????????int?second?=?this.second(); ??????????????????????if(second>50){ ????????????????????????????????int?third?=?this.third(); ????????????????????????????????if(third?>50){ ??????????????????????????????????????????this.first(); ????????????????????????????????} ??????????????????????} ?????????????????}?????????????? ?????} } 將三個步驟的訪問權限修改為private，同時把InstallSoftware中的方法installWizad移動到Wizard方法中。通過這樣的重構后，Wizard類就只對外公布了一個public方法，即使要修改first方法的返回值，影響的也僅僅只是Wizard本身，其他類不受影響，這顯示了類的高內聚特性。 對InstallSoftware類進行少量的修改，如代碼清單5-12所示。 代碼清單5-12 修改后的InstallSoftware類 public?class?InstallSoftware?{ ?????public?void?installWizard(Wizard?wizard){ ?????????????//直接調用 ?????????????wizard.installWizard(); ?????} } 場景類Client沒有任何改變，如代碼清單5-10所示。通過進行重構，類間的耦合關系變弱了，結構也清晰了，變更引起的風險也變小了。 一個類公開的public屬性或方法越多，修改時涉及的面也就越大，變更引起的風險擴散也就越大。因此，為了保持朋友類間的距離，在設計時需要反復衡量：是否還可以再減少public方法和屬性，是否可以修改為private、package-private（包類型，在類、方法、變量前不加訪問權限，則默認為包類型）、protected等訪問權限，是否可以加上final關鍵字等。 注意　迪米特法則要求類“羞澀”一點，盡量不要對外公布太多的public方法和非靜態的public變量，盡量內斂，多使用private、package-private、protected等訪問權限。 3. 是自己的就是自己的 在實際應用中經常會出現這樣一個方法：放在本類中也可以，放在其他類中也沒有錯，那怎么去衡量呢？你可以堅持這樣一個原則：如果一個方法放在本類中，既不增加類間關系，也對本類不產生負面影響，那就放置在本類中。 4. 謹慎使用Serializable 在實際應用中，這個問題是很少出現的，即使出現也會立即被發現并得到解決。是怎么回事呢？舉個例子來說，在一個項目中使用RMI（Remote Method Invocation，遠程方法調用）方式傳遞一個VO（Value Object，值對象），這個對象就必須實現Serializable接口（僅僅是一個標志性接口，不需要實現具體的方法），也就是把需要網絡傳輸的對象進行序列化，否則就會出現NotSerializableException異常。突然有一天，客戶端的VO修改了一個屬性的訪問權限，從private變更為public，訪問權限擴大了，如果服務器上沒有做出相應的變更，就會報序列化失敗，就這么簡單。但是這個問題的產生應該屬于項目管理范疇，一個類或接口在客戶端已經變更了，而服務器端卻沒有同步更新，難道不是項目管理的失職嗎？