# 六角鼠年鐵人賽 Week 39 - Design Pattern - Least Knowledge Principle

==大家好，我是 "為了拿到金角獎盃而努力著" 的文毅青年 - Kai==

## 張忠謀
:::info
我工作，所以我存在
:::

## 前引
在前幾篇文章講述了不少關於 Interface 的設計原則後，這次來講講實體類別之間的處理。

在學程式的一開始，常常會在一支程式中不斷引用套件、不斷使用其他類別，而後學到模組化時，懂得開始把大功能切割出去，分成個別細項的程式。在這其中總是有幾個類別總是常常被各個功能使用，當今天要替換這些類別的時候，還得去每一支有呼叫他們實體做修改，是件非常煩人的事情，同時也表示該程式與這些類別的耦合程度非常高，這會提高做修正或擴展時，牽涉到各功能的風險，以及不容易維護等缺點。

因此後來會學到的做法就是在這些程式中先宣告這些類的介面，透過 set() 這種方式把要使用的類別實體給放入其中。

這觀念就是這篇要介紹的 **Least Knowledge Principle**

## 主題
**Least Knowledge Principle**

中文常見名稱 **最少知識原則 (迪米特法則)**

是來自於 1987 年，Northeastern University 一個叫做 **Demeter** 的研究項目，因此又可以稱為 **Law of Demeter** (LoD)。

其定義於原文中寫道:「**Talk only to your immediate friends and not to strangers**」，意思即為如果兩個實體類無須互相呼叫，則應該避免直接使用或被使用的狀況，應透過第三方類進行呼叫，降低兩個實體類之間的高耦合狀況，提高實體類的獨立性。

這其實就是常見的：透過抽象，代替實體進行實體類的方法串接。

## 幫助
Least Knowledge Principle 的應用將會幫助系統達到以下效果:
- 降低類別與類別的耦合
- 提高模組獨立性
- 提高擴展可能性
- 保持系統結構清楚

## 實例
Kai 這邊拿一個公司作舉例，公司需要 Manager, Saler, Engineer 一起合作完成所謂的會議報告，在會議報告中需要不同部門個別的報告，在 Company 中若分別帶入了 Manager, Saler, Engineer 實體，並且呼叫個別的 report ()，到這邊都沒問題。

但若是今天 Saler1 換成 Saler2，變成不同實體的時候，我們就需要手動到 Company 中修正。
這樣的做法在該 Saler1 實體被大量類別使用的時候會異常麻煩去作修正，而且非常不彈性，甚至若有狀況是根據條件不同去使用 Saler1 或 Saler2 的話會更麻煩處理。

根據 **Least Knowledge Principle**，我們將 Manager, Saler, Engineer 修正為 Interface ，並將原先的類別作成不同的實作類別，把 Company 原先寫好的實體給換成 Interface 的宣告，並增加 set() 方法，待有需要的時候在放入適當的實體類別，即可降低 Company 對 Manager, Saler, Engineer 的高耦合情況。

:::danger
又過了一週，又學習到一個新的 Principle，希望大家都能與 Kai 一起慢慢把基本功紮實起來吧!
:::

首頁 [Kai 個人技術 Hackmd](/2G-RoB0QTrKzkftH2uLueA)

###### tags: `Design Pattern`,`w3HexSchool`