Skip to main content

SOLID 原則

SOLID 原則 是物件導向設計中非常重要的五大原則，它們有助於讓程式碼更容易理解、維護、擴充與測試。SOLID 是五個設計原則的縮寫，各字母代表一個原則：

S - Single Responsibility Principle（單一職責原則）​

一個類別應該只有一個引起它變化的原因。

簡單說就是「一個類別只做一件事」，這樣如果需求變動，只會影響到這個類別中的某個功能，不會牽一髮動全身。

📌 範例：

一個 Report 類別不應該同時負責產出報告和把報告輸出成 PDF，輸出功能應該拆出去，例如 PdfExporter。

O - Open/Closed Principle（開放封閉原則）​

程式應該對擴充開放、對修改封閉。

也就是說，我們應該能夠透過擴充功能而不是修改既有程式碼來應對需求變化，這樣比較安全也比較穩定。

📌 範例：

一個繪圖程式中如果要新增「畫圓形」功能，不應該修改原本的繪圖邏輯，而是新增一個 Circle 類別實作共通介面，如 Shape。

L - Liskov Substitution Principle（里氏替換原則）​

子類別應該可以替換其父類別，而且行為應該是一致的。

如果一個子類別無法完全取代父類別，那麼這樣的繼承關係可能就是錯的。

📌 範例：

假設有一個 Bird 類別有 fly() 方法，那麼繼承它的 Penguin 類別（企鵝不能飛）就不應該存在這樣的方法，應該重新設計類別結構。

I - Interface Segregation Principle（介面隔離原則）​

不應強迫用戶依賴他們不使用的方法。

應該將龐大的介面拆分成多個精簡的介面，讓類別只需要實作它真正需要的部分。

📌 範例：

不要讓 Worker 介面裡包含 eat()、work()、sleep()，而是拆成 Workable、Eatable 等獨立的介面。

D - Dependency Inversion Principle（依賴反轉原則）​

高層模組不應該依賴低層模組，兩者都應依賴抽象；抽象不應該依賴細節，細節應該依賴抽象。

簡單來說就是「依賴介面，不要依賴實作」。

📌 範例：

一個 NotificationService 不應該直接依賴 EmailSender，而是依賴一個像 INotificationSender 的介面，這樣就能輕易替換成 SmsSender 或 PushSender。