Design Pattern｜用 JS 來了解「迪米特原則 (最少知識原則)」 — Law of Demeter (LoD) | Least Knowledge Principle (LKP)
剛好最近自己在鑽研「Design Pattern」跟「Design Principle」，原本只是打算寫在自己的 Notion，但想想既然都要寫了，就把這系列分享出來給大家好了！而且這種主題討論性本來就滿大的，也希望如果有高手有不同的見解可以多多跟我交流一下！
什麼是「迪米特原則」？
- 一個單元對其他單元的了解應該有限
- 一個單元只能與其直接的朋友交談，而且不用知道太多
- 一個單元不應該和陌生人交談
上面這些特性文鄒鄒的，想必大家第一次看到也看不懂（因為我就是哈哈），下面會詳細解釋一下，其實說穿了就是想要降低對象與對象之間的「耦合度」。
「對象」：這裡的對象不僅僅是針對「類」，「函式」跟「模組」也是。
「耦合度」：耦合度在說的就是兩個對象之間的「緊密程度」，如果兩個對象耦合度太高就會造成「可重用性」、「可維護性」的困難，試想一個對象跟太多對象相關聯又關聯太深的話，改每一行 code 都心驚膽顫會影響到其他功能的對吧？
何謂「朋友」跟「陌生人」？
這裡附上百度上面的解釋
- 以參量形式傳入到當前對象方法中的對象
- 當前對象的實例變量直接引用的對象
- 當前對象的實例變量如果是一個聚集，那麼聚集中的元素也都是朋友
- 當前對象所創建的對象
任何一個對象，如果滿足上面的條件之一，就是當前對象的“朋友”；否則就是“陌生人”。
以簡單商店購物舉例
這裡看起來功能算是完善的，但是其中有一個問題，如果 Customer 想要「其他的方式付款」，而不是「從錢包拿出錢付款呢」？
ShopKeeper 不應該對這個 Customer 這個「朋友」了解太深入，付款方式應該由 Customer 去決定即可，因此我們稍稍修改一下
客戶付款的方式是他們自已的事，我們「不需要深入」這個朋友太多，上面只是個示意，簡單來說，就是 Shopkeeper 只與 Customer 交談，而不再深入進去 CustomerWallet。
以 DOM 操作舉例
這裡我們不應該讓 birthday-message 跟 Happy Birthday 與 DOM 這個物件模型直接溝通，因為他們是「陌生人」，我們必須透過其他的對像橋接這兩個人才可以。
這樣做比起前面的例子，日後如果有其他需求需要擴充該功能，我們不用直接去動到 displayMessage 的邏輯，而是再新增一個新的對象就可以了。
優點 v.s 缺點
優點：可以提高「可重用性」跟「可維護性」
缺點：可能會有一堆中介對象，導致程式碼跳來跳去，因此也要注意使用的時機
結論
自己算是第一次分享 Pattern / Principle 這種議題比較廣的文章，如果有說錯或說得不好的地方再麻煩各位高手們鞭策一下小弟🙏，謝謝大家！
