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

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.補充

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

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

標籤：設計模式

上一篇：IconButtononPressed不作業|InkWellonTap不作業|撲

下一篇：設計模式七大原則—迪米特法則