許多工程師都有過類似的經驗：接手一份「能跑就好」的舊專案，或只是想改一個小功能，卻發現牽一髮動全身，改了 A 壞了 B，修了 B 又壞了 C；幾輪下來，程式碼愈來愈難以理解，沒有人敢輕易動它。

這種現象有個名字，叫做程式碼腐化（Software Rot）；它的成因不是因為工程師不夠努力，也不是因為程式語言本身的限制，而是因為程式碼在設計上缺乏清晰的邊界與結構，隨著時間累積，複雜度像滾雪球一樣不斷擴大。

程式碼腐化常見的三種症狀：

  • Fragility（脆弱性）：系統在意想不到的地方發生錯誤；改了一處邏輯之後，看似無關的另一個模組卻開始出錯，原因是它們之間存在隱藏的耦合。
  • Rigidity（僵化性）：每一個改動都需要修改大量的地方，工程師必須追蹤一長串的連鎖反應，導致任何變更的成本都極高。
  • Immobility（不動性）：某段邏輯明明可以在其他地方複用，卻因為它與太多其他元件糾纏在一起，根本無法單獨抽出來。

SOLID 就是為了系統性地對抗這三種症狀而誕生的。

SOLID 的由來

Robert C. Martin（人稱 Uncle Bob）是《Clean Code》與《Clean Architecture》的作者，也是敏捷宣言的共同簽署人之一，他在 2000 年代初期，將多年在軟體工程領域的觀察與實踐整理成文，提出了五個核心設計原則。

這五個原則各自在過去幾十年間分散出現於不同的學術論文與工程討論中，Uncle Bob 的貢獻在於將它們系統化，並賦予一致的框架；之後 Michael Feathers（《Working Effectively with Legacy Code》的作者）發現這五個原則的英文首字母恰好組成「SOLID」，這個縮寫從此沿用至今。

五個原則各自對應的英文全名與中文名稱：

  • S — Single-Responsibility Principle：單一職責原則
  • O — Open-Closed Principle：開放封閉原則
  • L — Liskov Substitution Principle：里氏替換原則
  • I — Interface Segregation Principle：介面隔離原則
  • D — Dependency Inversion Principle：依賴反轉原則

OOP 的四個基石，以及它們的局限

物件導向程式設計（OOP）提供了四個強大的工具：

  • 封裝（Encapsulation）：將資料與操作資料的方法包裝在一起，隱藏實作細節，只對外暴露必要的介面；這讓模組之間的邊界更清楚，也保護了資料不被任意存取。
  • 繼承（Inheritance）：讓子類別繼承父類別的屬性與行為，實現程式碼的複用；它也建立了「is-a」的型別關係，讓一個子類別的物件可以被當作父類別使用。
  • 多型（Polymorphism）：同一個介面或方法名稱，可以在不同的類別中有不同的實作；呼叫端只需要知道「這個物件能做什麼」，不需要知道「它是怎麼做的」，讓程式碼更具彈性。
  • 抽象（Abstraction）：透過介面（Interface）或抽象類別（Abstract Class），只定義行為的「輪廓」，而不指定實作，這讓高階的業務邏輯可以與低階的實作細節解耦。

然而這四個工具只是手段，本身並不保證良好的設計；一個大量使用繼承、卻讓子類別行為不一致的系統，可能比不用繼承更糟糕；一個把所有邏輯封裝在同一個「萬能類別」裡的設計，只是用封装帶來更大的隱患；OOP 告訴你可以做什麼，SOLID 告訴你應該怎麼做。

SOLID 如何指導 OOP 的使用

SOLID 五個原則並非獨立的規定，每一條都針對 OOP 的某個基石，告訴你它應該被如何正確使用：

  • SRP → 指導封裝（Encapsulation）的邊界：封裝告訴你「把相關的東西包在一起」，但什麼叫做「相關」呢？SRP 給出了答案：以職責（actor）劃定邊界，而非以技術上的方便性；一個類別只應封裝服務於同一個改變來源的行為，若一個類別同時管理業務規則、資料存取和通知發送，封裝只是把複雜度藏起來，而非真正消除它。
  • OCP → 指導多型（Polymorphism）的應用：多型讓同一個介面可以有不同的實作，OCP 告訴你何時、以及為何應該使用多型；當一段邏輯因為「同一類型的需求增加」而被反覆修改，就是引入多型的訊號，讓新行為以「新增類別」的方式加入，而非以「修改現有程式碼」的方式侵入，讓已穩定的邏輯保持封閉。
  • LSP → 指導繼承（Inheritance）的語義：繼承在語法上允許子類別覆寫任何父類別的方法，但 LSP 規範了繼承的道德底線：子類別只能繼承父類別的行為契約，而不能破壞它；「覆寫」的意義應是「更具體的實作」，而非「改變承諾的內容」，若子類別無法在不破壞父類別契約的前提下繼承，那繼承本身就是錯誤的選擇。
  • ISP → 指導抽象（Abstraction）的精準度：抽象（介面）的目的是「只暴露必要的能力」，而 ISP 要求這個「必要」必須是精準的：一個介面只描述一種角色，不應因為便利而把多種無關的能力混在同一個介面裡；過大的介面讓呼叫端依賴它根本不需要的方法，讓實作者被迫提供無意義的空實作，模糊了抽象本該帶來的清晰邊界。
  • DIP → 指導抽象（Abstraction）與多型（Polymorphism）的方向性：抽象和多型本身只是工具，DIP 指定了它們應該被用來做什麼：讓依賴關係的箭頭指向抽象，而非指向具體實作；高階模組（業務邏輯）定義它所需要的介面，低階模組（技術實作）去實作這個介面，依賴方向因此「反轉」，這確保業務邏輯的穩定性不受技術選型的變動所影響。

五原則的全局觀

在深入每一個原則之前，先從高空俯瞰它們各自解決的核心問題：

  • SRP（單一職責）：一個類別只有一個改變的理由；它解決的是「上帝類別（God Class）」的問題，一個什麼都做、什麼都管的類別，任何需求變更都需要改動它。
  • OCP（開放封閉）：對擴展開放，對修改封閉；它解決的是每次新增功能都需要到處修改現有程式碼，即「散彈槍手術（Shotgun Surgery）」的問題。
  • LSP（里氏替換）：子類別可以安全地替換父類別，且不改變程式的正確性。它解決的是子類別破壞了父類別建立的行為預期，即「繼承濫用」的問題。
  • ISP（介面隔離）：不強迫類別實作它不需要的介面方法；它解決的是「肥大介面（Fat Interface）」的問題：一個介面包含太多無關的方法，讓實作者不得不撰寫無意義的空實作。
  • DIP（依賴反轉）：高階模組與低階模組都應依賴抽象，而非彼此直接依賴；它解決的是「高耦合（Tight Coupling）」的問題：業務邏輯與技術實作細節緊密相連，無法獨立測試與替換。

五個原則之間的協作關係

SOLID 不是五條互不相干的規則，它們在實務中相互支撐、彼此強化：

  • 遵守 DIP 通常需要同時設計精簡的介面，這正是 ISP 的要求。
  • OCP 的實現依賴多型，而多型的正確性需要 LSP 作為基礎保障。
  • SRP 與 ISP 在不同層次解決同一問題：一個作用於類別的職責邊界，另一個作用於介面的能力邊界。
  • 全面實踐 SOLID 的系統，往往天然具備良好的可測試性，因為每個元件都職責清晰、依賴明確，可以獨立替換和驗證。

學習 SOLID 最常見的誤區，是把這五個原則當作「必須時刻遵守的鐵律」，更好的理解方式是把它們視為設計決策的指南針：當你面對一個複雜的設計問題時，這五個原則幫助你思考「這樣設計，未來會付出什麼代價？」

Uncle Bob 本人也強調，SOLID 是用來對抗過度複雜的處方，而非鼓勵過度設計的藉口；在小型腳本或一次性工具中，嚴格遵守 SOLID 反而可能增加不必要的抽象層，讓程式碼更難理解。

建議的學習路徑：依序閱讀並找到自己現有的程式碼，試著用那一篇的視角重新審視它；理解一個原則最快的方式不是死記定義，而是在真實的程式碼中親自感受它被違反時帶來的痛苦。