# 最少知識原則(LKP: Least Knowledge Principle)
###### tags: `Design Patterns` `book` `principle`

當設計實作一個類別時，這個類別應該越少使用到其他類別提供的功能越少。意思是，當這個類別能夠只依本身的「知識」去完成功能的話，那麼就相對地減少與其它物件「知識」的依賴度。這樣的好處是減少這個類別與其它類別的耦合度，換個角度來看，就是增加這個類別被不同專案共同的可能性，而這將提供類別的重用性。

## 少用繼承多用組合

當子類別繼承了一個「介面類別」後，新的子類別就要負責重新實作介面類別中所定義的方法，而且不該額外擴充介面，以符合上述多個設計原則的要求。但是，當系統想要擴充或增加某一項功能時，讓子類別繼承舊有的實作類別，卻也是最容易實現的方式之一。新的子類別在繼承父類別後，在子類別內增加想要擴充的「功能方法」並加以實作，客戶端之後就能直接利用子類別物件進行新增功能的呼叫。

但對於客戶端或程式設計師而言，當下他可能只是需要子類別所提供的功能，並不想額外知道父類別的功能，因為這樣會增加程式設計師在挑選方法時的難度。例如，「鬧鐘類別」可以利用繼承「時鐘類別」的方式，取得「時間功能」的實作，只要子類別本身在另外加上「定時提醒」的功能，就能達成「鬧鐘功能」的目標。當客戶端使用鬧鐘類別時，可能期待的只不過是設定鬧鐘時間的方法而已，對於取得目前時間的功能並沒有迫切的需求。故而，從時鐘父類別繼承而來的方法，對於鬧鐘的使用者來說，可能是多餘的。

那麼如果將設計改為，在鬧鐘的類別定義中，宣告一個型別為時鐘類別的「類別成員」那麼就可以減少不必要的方法出現在鬧鐘介面上，也可以減少內鐘類別的客戶端對時鐘類別的相依性。另外，在無法使用多重繼承的程式語言(如Java)中，使用組合的方式會比層層繼承來得明白及容易維護，並且對於類別的封裝也有比較好的表現方式。

所以，在說明完上述幾個物件導向設計原則之後，可以知道的是，物件導向程式設計強調的是，在進行軟體分析時必須遵循著指導原則，而設計模式基本上都會秉持著這些原則來進行設計，也可以這樣說，「設計模式」是在符合「物件導向設計原則」的前提下，解決軟體設計問題的實際呈現結果。