使用函式的得墨忒耳法則來解耦 編寫「羞怯」的**：
包含兩層意思，乙個是不向別人暴露你自己，不會沒必要的向其他模組暴露任何事情；另乙個是不與太多人打交道，不依賴於其他模組實現的模組。
不與太多人打交道，說的就是要降低與別人的耦合，比如你的模組a依賴於乙個模組b的功能，那麼你就僅僅呼叫這個模組b的功能，而不要呼叫這個模組的實現中出現的模組c的功能，因為，一旦b的模組實現方式改變，那麼c可能不存在，或者c出現了變動，那麼它的影響就不僅僅是b，還有a也受到了影響。而如果a只呼叫b，則即使b的實現去掉了c模組，那麼只要b的介面不變，那麼a是不受影響的，或者如果c變了，那麼由於a只呼叫b，則c的變動影響的只會是b，而不會影響a。因此，耦合性強的系統，改變**將會變得非常困難，牽一髮而動全身。
函式的得墨忒耳法則試圖使任何給定程式中的模組之間的耦合減至最少，它設法阻止你為了獲得對第三個物件的方法的訪問而進入某個物件。
法則規定：某個物件的任何方法都應該只呼叫屬於以下情況的物件的方法：
1.這個物件自己擁有的方法；
2.傳入該方法的引數的方法；
3.該方法建立的物件的方法；
4.該物件直接擁有的物件的方法；
**如下：
class a
public void methoda(c c)
} 當然，得墨忒耳定律中，由於不建議呼叫依賴模組b的實現的模組c，因此，你不得不編寫大量的包裝方法，這些方法只是把請求**給被委託者。存在執行時代價和空間開銷，如果你很在乎這些，那麼你不得不在效能和可維護性靈活性之間做個平衡，比如為了效能而使某些模組緊密耦合。呵呵，有時為了效能不得不『反規範化』，就像在資料庫設計中，為了提高訪問速度，避免聯合查詢，而對某些字段採用冗餘一樣。
因此不建議呼叫任何函式返回的物件的方法–只跟朋友談話，不與陌生人談話。eg：
a.getb().getc();
附件：維基百科對「得墨忒耳定律」的解釋
得墨忒耳定律（law of demeter，縮寫lod）也叫做「最少知識原則」，是一種開發軟體的設計原理，特別是物件導向的程式設計，得墨忒耳定律是松耦合的一種特殊情況。該指導原則是2023年末在美國東北大學發明的，該原則可以簡單地概括為以下方式之一：
1每個單元對於其他的單元只能擁有有限的知識：只是與當前單元緊密聯絡的單元；
2每個單元只能和它的朋友交談：不能和陌生單元交談；
3只和自己直接的朋友交談。 這個原理的名稱**於希臘神話中的農業女神，孤獨的得墨忒耳。
ps: law of demeter, 中文翻譯 迪公尺特 或者 得墨忒耳 法則，貌似翻譯為前者的比較多，但是程式設計師修煉之道中翻譯為後者。
函式的得墨忒耳法則
得墨忒耳定律也叫做 最少了解原理 是一種軟體設計原理，尤其是應用到物件導向的程式設計中，基本原理為 每個物件對其他物件只能有最少的了解 只有總體才能接近個別物件 每個物件只能和自己的朋友對話 不要和陌生人說話 只和自己最親密的朋友對話。c sharp view plain copy 函式的得墨忒耳法...
迪公尺特法則
定義 乙個物件應該對其他物件保持最少的了解。問題由來 類與類之間的關係越密切，耦合度越大，當乙個類發生改變時，對另乙個類的影響也越大。解決方案 盡量降低類與類之間的耦合。自從我們接觸程式設計開始，就知道了軟體程式設計的總的原則 低耦合，高內聚。無論是面向過程程式設計還是物件導向程式設計，只有使各個模...
迪公尺特法則
自從我們接觸程式設計開始，就知道了軟體程式設計的總的原則 低耦合，高內聚。無論是面向過程程式設計還是物件導向程式設計，只有使各個模組之間的耦合盡量的低，才能提高 的復用率。怎麼樣程式設計才能做到低耦合呢？那正是迪公尺特法則要去完成的。類與類之間的關係越密切，耦合度越大，當乙個類發生改變時，對另乙個類...