設計模式七大原則—迪米特法則

1.概念

1.1.知道的越少越好

迪米特法則，結合其含義又稱之為“最少知道原則”，即一個類作為一個調用方，應當對自己依賴的類(被調用的類)其中所處理的邏輯細節，知道的越少越好。對於被依賴的類(被調用的類)不管在使用上多麼的複雜，它都應儘量將處理邏輯封裝在它的內部，對調用方提供簡潔明瞭的公共方法即可，以此減輕上層調用方過多承擔複雜邏輯的壓力和變化。

1.2.朋友和陌生人

對於程式編碼設計是否遵循了“迪米特法則”，我們通常可以使用一段經典的描述來判斷，該描述是：“只和朋友通信，不和陌生人說話”。那麼對於這段話中什麼是朋友，什麼是陌生人，下麵對其進行一個介紹。

每個對象都會與其他對象之間都存在一定程度的耦合關係，其中主要耦合方式包含：依賴、關聯、組合、聚合等等。如果某個類作為被調用者，在其調用方的類中的內部主要體現為：類中成員變數的類型、方法參數類型、方法返回值類型，那麼該類就屬於調用者的“朋友”。

對於某個類而言，當它作為“被調用者”在“調用者”當中沒有作為：類中成員變數的類型、方法參數類型、方法返回值類型，這些形式出現在類中，而是僅作為局部變數出現在某個方法體中，那麼對於這種情況，該類就屬於“陌生人”。

1.3.高內聚低耦合

如果類在編寫時產生了大量與“陌生人說話”，那麼這樣會導致依賴的類具有隱匿性，如果“陌生人”發生改動，那麼其他使用“陌生人”的類(調用方)很難精確的做出協調，需要改動的地方也很難預估，這樣就加劇了類與類之間的耦合程度，你很難斷絕對某個類的依賴。

另外，本來處理邏輯是類自己內部可以處理的，如果非要將處理邏輯帶到上層(調用方)，這樣就導致上層(調用方)違背了“最少知道原則”，並且不符合高內聚(自己的事情自己做)。

由此可見，迪米特法則的核心思想就是讓編碼設計實現：高內聚，低耦合。

2.舉例

我們的程式最終要想實現迪米特法則”，其實就是遵循“最少知道原則”，具體實現這個原則就要程式做到“只和朋友通信，不和陌生人說話”。這些介紹在理解層面上都是相對抽象的，接下來我將通過生活中的例子和代碼來更通俗的體會迪米特法則。

2.1.生活場景

在實際的生活當中，人們都可以通過點外賣的方式來解決自己用餐的需求，接下來我將以點外賣解決用餐需求作為背景，來類比“迪米特法則”中的概念。

張三心血來潮突然想吃“全聚德”的菜餚，但是他又不想出門走上幾公裡的路去門店吃。於是他在網上查找發現了“全聚德”剛剛開設的外送模式，他哽咽著口水趕忙的打電話預定了外送訂單。

由於“全聚德”在外送模式下剛剛開設還在起步階段，有些外送門路還不是很瞭解，全聚德一開始將外送員、廚師、食材一起帶到張三家，在張三家現場製作菜餚。在家中現場製作的過程中經常發生一些問題：張三在看到製作流程後經常會指手畫腳導致味道“四不像”、廚師由於身體情況做了幾道菜後就經常去拉肚子導致糊鍋。

這些問題導致了張三並沒有享受到了外送模式的便捷，因為當前的外送模式，全聚德讓張三知道了太多的菜餚製作細節並且於過多的人產生聯繫，對於這個場景參照到“迪米特法則”來說，就是沒有讓使用方(張三)遵循“最少知道原則”，讓使用者過多知道一些細節，從而增加了複雜程度。

另外在外送模式下，全聚德讓過多的人員參與到了外送當中，其中有外送員、廚師、食材。其實張三作為顧客並不用和廚師、食材打交道，這樣只會增加用餐的依賴程度，張三其實只用和餐館的外送員打交道即可。那麼這裡的場景參照到“迪米特法則”當中，對於外送員而言和張三就是“朋友”，廚師、食材是“陌生人”，上面的例子中，廚師在現場製作菜餚經常因為身體情況拉肚子，就是體現出依賴了“陌生關係”，從而增加了耦合度並因此帶來不可預估的風險。

“全聚德”為了實現更好的外賣用餐體驗，使用迪米特法則對外送模式進行改良，之後的張三在不用關心更多的菜餚製作細節和對廚師的依賴，他只用接到外送員外送的菜餚，就可以快捷的享受到美食。

2.2.代碼案例

在通過生活場景和迪米特法則概念進行類比後，我們接著這個例子通過代碼案例在加深對迪米特法則的理解，以及使用它的好處。代碼案例有兩種形式，一種是沒有遵循迪米特法則的例子，另一個是遵循了迪米特法則的例子，後者是針對前者存在問題改進，通過對比的形式更能突出該原則的優勢。

 未使用迪米特法則

 1     class Person
 2     {
 3 
 4         public void 點外賣(外送員 foodDelivery,string 菜名)
 5         {
 6             廚師 張大師= foodDelivery.通知餐館安排人員製作菜餚();
 7             var 菜餚=  張大師.烹飪(菜名);
 8 
 9             foodDelivery.送餐(菜餚);
10 
11             Console.WriteLine($"送餐成功，開始吃{菜餚}");
12 
13         }
14     }
15 
16     class 外送員 
17     {
18         public 廚師 通知餐館安排人員製作菜餚()
19         {
20             return new 廚師();
21         }
22         public string 送餐(string 菜餚)
23         {
24             Console.WriteLine("根據路線進行送餐");
25             return 菜餚;
26         }
27     }
28 
29     class 廚師
30     {
31         public string 烹飪(string 菜名)
32         {
33             Console.WriteLine("烹飪製作");
34             return 菜名;
35         }
36     }

我們主要看Person類中的代碼，Person類在當前代碼中作為一個調用者(使用方)，在點外賣的方法中使用到了兩個類，一個是外送員類和廚師類。那麼基於本文中對“朋友與陌生人”的概念，此時的朋友其實就是外送員類，因為它作為一個方法的參數類型包含在類中，是符合朋友的標準。對於廚師類而言就是陌生人，因為它作為局部變數在類的方法中，那麼對於以上代碼很顯然就違反了迪米特法則。

使用迪米特法則

 1     class Person
 2     {
 3 
 4         public void 點外賣(外送員 foodDelivery,string 菜名)
 5         {          
 6           var 菜餚= foodDelivery.送餐(菜名);
 7             Console.WriteLine($"送餐成功，開始吃{菜餚}");
 8         }
 9     }
10 
11     class 外送員 
12     {
13         public 廚師 通知餐館安排人員製作菜餚()
14         {
15             return new 廚師();
16         }
17         public string 送餐(string 菜名)
18         {
19             var 菜餚 =  通知餐館安排人員製作菜餚().烹飪(菜名);
20            
21             Console.WriteLine("根據路線進行送餐");
22             return 菜餚;
23         }
24     }
25 
26     class 廚師
27     {
28         public string 烹飪(string 菜名)
29         {
30             Console.WriteLine("烹飪製作");
31             return 菜名;
32         }
33     }

通常作為顧客並不關心菜餚的製作過程或外送員送餐的路線，他只關心外送員能夠在預期時間進行送餐，使他能吃上飯。所以該代碼案例主要將菜餚的製作環節從Person類中取掉，將菜餚的製作推向外部，這樣就做到了讓Person類遵循“最少知道原則”，另外切斷點外賣方法中與廚師類(陌生人)的聯繫，促使Person類只和“朋友通信”（外送員），這樣就實現了迪米特法則。

3.補充

類與類之間的耦合是不可避免的，遵循迪米特法則並不是完全解除依賴，而是在一定程度上降低類與類之間不必要的依賴。例如其中的某個概念：“不和陌生人說話”，這就並不是一個能夠完全杜絕的情況，我們只能儘量的不要讓陌生的類作為局部變數出現在類的內部，並且保障類對自己依賴的類知道的越少越好。

這從側面也反映了設計模式原則並不是一個教條，而必須遵守，作為編碼者更重要的是提煉其中的思想，根據實際的情況儘量的讓程式設計做到最大化的“高內聚，低耦合”。