資訊專欄INFORMATION COLUMN
摘要：個人博客原文迪米特法則設計模式六大原則之五迪米特法則。老師便給同學們講解了這個例子，讓學生感受一番迪米特法則。總結迪米特法則主要講述的觀點是高內聚低耦合。
個人博客原文:
迪米特法則
設計模式六大原則之五：迪米特法則。簡介
姓名：迪米特法則
英文名：Law of Demeter
小名：最少知識原則
小名英文名：Least Knowledge Principle
價值觀：媽媽說不和陌生人說話
個人介紹：
Each unit should have only limited knowledge about other units: only units "closely" related to the current unit. (每個單元對于其他的單元只能擁有有限的知識：只是與當前單元緊密聯系的單元)
Each unit should only talk to its friends; don"t talk to strangers. (每個單元只能和它的朋友交談：不能和陌生單元交談)
Only talk to your immediate friends. (只和自己直接的朋友交談)
(來自維基百科)
還是腦洞大開來個小故事。這故事還是比較現實一些，其實也不算是故事，就是咱們經常經歷的事情，現在知識付費已經廣受歡迎，18 年底更是快速猛漲，各種各樣的培訓、讀書、音頻學習軟件如雨后春筍一般涌現出來。我們就拿一個讀書的例子。
有一天，設計模式老師講解了迪米特法則，同學們聽得云里霧里的，老師怕同學們沒掌握這個知識點，就給同學們布置了一個作業，需要同學們按迪米特法則實現。
作業是這樣子的：平常在零碎的時間里，喜歡看一些書籍，一般都是電子書，現在我們看書的操作是這樣的：喚醒手機，打開閱讀軟件，選擇書籍，然后閱讀?？偣?3 個步驟，涉及了 3 樣東西：手機、軟件、書籍。同學們用代碼實現這個過程。
第二天上課，同學們紛紛交了作業，老師隨手一番，就看到了 2 個鮮明的例子，很明顯，就是一好一壞。老師便給同學們講解了這 2 個例子，讓學生感受一番迪米特法則。
錯誤例子public class LODErrorTest {
public static void main(String[] args) {
Phone phone = new Phone();
phone.readBook();
}
}
/**
* 錯誤的示范
*/
class Phone {
App app = new App();
Book book = new Book("設計模式");
public void readBook() {
app.read(book);
}
}
class App {
public void read(Book book) {
System.out.println(book.getTitle());
}
}
class Book {
private String title;
public Book(String title) {
this.title = title;
}
public String getTitle() {
return title;
}
public void setTitle(String title) {
this.title = title;
}
}
代碼：
LODErrorTest
代碼是完成了讀書這個過程，看樣子是功能實現了，細看會發現代碼的邏輯不對。哪里不對呢？書籍和應用對象都在手機上，現實是我們喚醒手機，這時手機是沒有書籍的，只有當我們打開閱讀軟件，才有書籍可以看，沒有閱讀軟件，書籍是看不了的。因此，手機和書籍沒有一毛錢關系，書籍不應該在手機里面。正常的設計是：手機里面有閱讀軟件，閱讀軟件里面有書籍，這才符合迪米特法則，按定義來說：手機和閱讀軟件是朋友，閱讀軟件和書籍是朋友，可是朋友的朋友不是朋友，也就是手機和書籍不是朋友，所以它們不應該有交集，應該離得遠遠的。
思考一下現實：工作中如果缺少代碼復核這個步驟，就會出現這樣子，后果是怎么樣呢？會給后人挖坑，而且是大坑，因為和現實中的邏輯是對不上的，況且后人不知道當時的業務背景，只能看代碼去熟悉，就會一步錯、步步錯，所以要好好把控代碼質量這一關，因為代碼千人千面，沒法要求代碼風格全部一致，但至少需要實現邏輯是清晰易懂的。
正確例子public class LODRightTest {
public static void main(String[] args) {
Phone2 phone2 = new Phone2();
phone2.readBook();
}
}
/**
* 正確的示范
*/
class Phone2 {
private App2 app2 = new App2();
public void readBook() {
app2.read();
}
}
class App2 {
private Book2 book2 = new Book2("設計模式");
public void read() {
System.out.println(book2.getTitle());
}
}
class Book2 {
private String title;
public Book2(String title) {
this.title = title;
}
public String getTitle() {
return title;
}
public void setTitle(String title) {
this.title = title;
}
}
代碼：
LODRightTest
這段代碼就符合迪米特法則，手機中有閱讀軟件，閱讀軟件中有書籍，手機沒有書籍任何影子。正確代碼不用細講，用心去感受就可以體會到。
總結迪米特法則主要講述的觀點是高內聚、低耦合。我理解為：是你的，就別給別人；不是你的，就別拿。上面定義的朋友也是這個意思。
參考資料：《大話設計模式》、《Java設計模式》、《設計模式之禪》、《研磨設計模式》、《Head First 設計模式》
寫到這，第五個原則了，六大原則就剩下最后一個開閉原則，湊齊 6 把大刀就可以準備去大干 23 個大漢啦。。。想想都激動。
希望文章對您有所幫助，設計模式系列會持續更新，感興趣的同學可以關注公眾號，第一時間獲取文章推送閱讀，也可以一起交流，交個朋友。
公眾號之設計模式系列文章
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/72834.html
摘要：單一職責原則開閉原則里氏替換原則依賴倒置原則接口隔離原則迪米特法則組合聚合復用原則單一職責原則高內聚低耦合定義不要存在多于一個導致類變更的原因。建議接口一定要做到單一職責，類的設計盡量做到只有一個原因引起變化。使用繼承時遵循里氏替換原則。 單一職責原則 開閉原則 里氏替換原則 依賴倒置原則 接口隔離原則 迪米特法則 組合/聚合復用原則 單一職責原則（Single Responsi...
摘要：常用的六大設計模式有單一職責原則，里氏替換原則，依賴倒轉原則，接口隔離原則，迪米特法則，開閉原則。這六大原則是最虛，最抽象的，很難理解。這就是接口隔離原則。當我們遵循前面介紹的五大原則，以及使用種設計模式的目的就是遵循開閉原則。 設計模式的目的是為了更好的代碼重用性，可讀性，可靠性和可維護性。常用的六大設計模式有：單一職責原則（SRP），里氏替換原則（LSP），依賴倒轉原則（DIP...
摘要：依賴倒置原則是個設計原則中最難以實現的原則，它是實現開閉原則的重要途徑，依賴倒置原則沒有實現，就別想實現對擴展開放，對修改關閉。 1、單一職能原則（Single Responsibility Principle, SRP） 定義 There should never be more than one reason for a class to change.應該有且僅有一個原因引起類的...
摘要：六開閉原則開閉原則簡介開閉原則的英文名稱是，簡稱。開閉原則是面向對象設計中最基礎的設計原則，它指導我們如何建立一個穩定靈活的軟件系統。 面向對象基本原則（3）- 最少知道原則與開閉原則 面向對象基本原則（1）- 單一職責原則與接口隔離原則面向對象基本原則（2）- 里式代換原則與依賴倒置原則面向對象基本原則（3）- 最少知道原則與開閉原則 五、最少知道原則【迪米特法則】 1. 最少知道...
閱讀 3218·2023-04-26 01:30
閱讀 679·2021-11-08 13:15
閱讀 1801·2021-09-24 10:35
閱讀 1015·2021-09-22 15:41
閱讀 1938·2019-08-30 15:44
閱讀 608·2019-08-30 13:22
閱讀 1017·2019-08-30 13:06
閱讀 1210·2019-08-29 13:22
