Unity C# | 物件導向五大設計原則（SOLID）

前言

1. 單一職責原則（SRP: Single Responsibility Principle）

現象 | 累加再累加

　　設計師一開始不太容易實現這個原則，在專案開發的過程中，不斷地往同一個類別上增加功能，最後導致類別過於龐大、介面過於複雜後才會發現問題。

建議 | 類別重構

　　將類別中與實作相關功能的部分抽取出來，另外封裝維新的類別，之後再利用組合的方式將新增的類別加入原類別之中，慢慢地就能達成單一職責化的需求。

2. 開放封閉原則（OPC：Open-Closed Priciple）

建議 | 功能介面化

　　將系統功能的「操作方法」向上提升，抽象畫為「介面」，將「功能的實作」往下一到子類別中。

1. 重新實作一個新的子類別。
2. 繼承舊有的實作類別，並在新的子類別中實作新增的系統功能。

3. 里氏替代原則（LSP：Liskov Substitution Principle）

4. 相依性反向原則（DIP：Dependence Inversion Principle）

• 高層模組不應該相依於低層模組，兩者都應該相依於抽象概念。
• 抽象介面部應該相依於實作，而實作應該相依於抽象介面。

介紹 | 汽車

　　汽車就是所謂的高層模組，它由引擎系統、傳動系統、懸吊系統、車身骨架系統、電裝系統等，有了低層模組的相互配合才完成一部汽車。

　　然而汽車卻很容易被引擎給限定，也就是說，裝載無鉛汽油的汽車不能使用柴油做為燃料；裝載柴油引擎的汽車不能使用無鉛汽油作為燃料，這就是「高階模組相依於低層模組」的例子。

介紹 | 個人電腦

　　電腦是高層模組，定義了 USB 介面，這個介面定義了硬體鎖需的規格及軟體驅動程式的撰寫規格，任何底層模組（記憶卡、隨身碟、讀卡機、相機、手機等）都能加入個人電腦的模組中。

總結 | 相依反轉

　　在個人電腦中，高層模組定義介面，低層模組再依照這個介面實作，這個過程可以讓他們之間的相依關係反轉，不用像汽車那樣被限制，同時也說明了「抽象介面部應該相依於實作，而實作應該相依於抽象介面」。

　　當高層模組定義好介面之後，底層模組的溝通就只能藉由介面來進行，這個介面可以是一個類別的變數或物件參考。

5. 介面分割原則（ISP：Interface Segregation Principle）

建議 | 介面分割

　　透過「功能的切分」及「介面的簡化」可以減少這類問題的發生，或是套用設計模式來重新規劃類別，也可以減少不必要的操作介面出現在類別中。

常用的其他原則

最少知識原則（LKP：Least Knowledge Principle）

　　當實作一個類別，這個類別應該越少使用到其他類別提供的功能越好，也就是說當個類別能夠只依照本身的「知識」去完成功能，就相對減少與其它物件「知識」的依賴程度。

這樣有兩個好處：

1. 減少此類別與其他類別的耦合度。
2. 增加被其他專案共用的可能性。

少用繼承多用組合

　　當子類別繼承一個「介面類別」後，新的子類別就要負責重新設計實作介面類別中所定義的方法，而且不該額外擴充介面，以符合上述多個設計原則的需求。

　　然而讓子類別繼承舊有的實作類別，卻也是最容易的實現方法之一，在子類別內增加想要擴充的「功能方法」並加以實作，客戶端之後就能直接利用子類別物件進行新增功能的呼叫。

　　例如，鬧鐘類別可利用繼承「時鐘類別」的方式，取得「時間功能」的實作，只要子類別加上定時提醒的功能，就能達成鬧鐘功能的目標，然而客戶端使用鬧鐘類別時，對於取得目前時間沒有需求，只是單純想設定鬧鐘時間而已。

建議 | 宣告類別

在鬧鐘的類別定義中，宣告一個型別為時鐘類型的「類別成員」，那麼就可以減少不必要的方法出現在鬧鐘介面上，也可以減少鬧鐘類別的客戶端對時中類別的相依性。

後記

瓶裝雪

參考資料