- SOLID 原則是可維護和可擴展軟體的基礎。
- 每個原則都涉及一個關鍵方面：凝聚力、擴展性、替代、解耦和靈活性。
- 正確應用它們有助於協作、測試和適應未來的變化。
軟體品質並非一時興起或曇花一現的潮流：它是任何技術項目在不斷變化的市場中擴展、發展和生存的基石。您是否曾經在缺乏結構或最佳實踐的情況下維護或嘗試改進應用程式？您肯定體會過每次寫一行程式碼都如臨大敵的滋味。 SOLID原則正是在這種情況下發揮作用：它們提供清晰的指導，只要結合常識應用，就能將脆弱且錯綜複雜的系統轉化為易於理解和長期維護的穩健解決方案。
SOLID並非一個易於記憶的縮寫，它代表著五個基本原則，能夠徹底改變我們在物件導向程式設計中設計類別、模組和架構的方式。如果您從事開發工作，應用 SOLID 將為團隊和個人專案帶來轉折點。本文將帶您了解SOLID 的所有精髓和高級內容：它的歷史、每項原則的深入解讀、實用範例、優勢、局限性，以及如何將它們整合起來，從而編寫出簡潔、可測試且健壯的程式碼。
什麼是 SOLID 以及這種方法是如何產生的？
SOLID不僅僅是一個縮寫：它概括了構成現代物件導向程式設計基礎的五個關鍵原則。這些原則出現在 20 世紀後期，當時軟體系統的複雜性日益增加，迫切需要解決諸如意大利麵條式代碼、面對變化時的僵化以及組件之間令人頭疼的耦合等問題。
SOLID 的起源可以追溯到 2000 年，當時羅伯特·C·馬丁（人稱「鮑伯叔叔」）在他那篇極具影響力的文章《設計原則與設計模式》中，根據自身經驗以及對成功和慘痛失敗案例的觀察，總結出了一系列建議。不久之後，麥可·費瑟斯創造了SOLID一詞，將這五項原則歸納並加以強調。這些原則結合起來應用，就能建構出高效率的系統。
- 可維護： 未來的發展是敏捷和安全的
- 可擴充： 做好成長準備，避免陷入混亂
- 易於理解： 任何團隊成員都可以加入並做出貢獻
- 低耦合、高內聚： 更改的影響最小，且程式碼可重複使用。
從那時起，SOLID 就被認為是物件導向軟體設計的基石，其影響擴展到了經典架構和當代方法（微服務、函數式程式設計和多範式）。
分解首字母縮寫：每個 SOLID 原則的意思是什麼？
SOLID這個縮寫由五個字母組成，每個字母代表一個原則：
- S – 單一職責原則（SRP）： 單一職責原則
- O – 開放/封閉原則（OCP）： 開放/封閉原則
- L – 里氏替換原則（LSP）： 里氏替換原則
- I – 介面隔離原則（ISP）： 介面隔離原則
- D –依賴倒置原則（DIP）： 依賴倒置原則
這些原則各自在最大限度地減少複雜性、最大限度地防止錯誤以及實現真正專業的程式碼結構方面發揮著特定作用。
SOLID 在現代開發中的重要性
SOLID原則的應用遠超過學術界的教條；在實際專案中，應用這些原則就等同於成功。諸如僵化的設計、循環依賴、測試困難以及臭名昭著的「這東西能用，但沒人知道為什麼」等問題，都是忽視最佳實踐的徵兆。
你想以團隊形式工作、共享程式碼並不斷改進架構嗎？採用 SOLID 原則可以幫助你避免以下問題：
- “上帝”課程： 做所有事情但最終成為 bug 來源的對象
- 不受控制的修改： 每次改進或修正都會引發錯誤的“蝴蝶效應”
- 無法重複使用程式碼： 複製貼上最終成為反覆出現的（糟糕的）解決方案
- 無法應用單元測試： 程式碼從未足夠解耦
- 動力不足，成本高： 每一個新的發展或整合都是不確定性和挫折的根源
因此，採用 SOLID 原則不僅可以讓開發人員的工作更輕鬆，還可以讓他們建立強大的項目，這些項目能夠不斷發展並適應不斷變化的業務需求。
原則 S：單一職責（SRP）
單一職責原則指出，每個類別或模組都應該只有一個變更理由。其根本目標是促進內聚性，即係統中的每個組件都專注於單一任務。
為什麼實踐起來這麼困難？因為人們常常傾向於為現有類別添加更多方法或功能，而不是建立一個新類別。然而，當一個類別具有多項職責時，對其中一項職責的改變可能會對其餘職責產生負面影響，產生無法預料的副作用。
經典範例：想像一個代表書籍的類，除了書籍本身的資料外，還包含列印、保存、發送通知等邏輯。這些功能各自回應不同的變更原因，最終破壞了單一職責原則 (SRP)。
解決方案在於將每項職責拆分到各自的類別中：一個類別用於儲存書籍數據，一個類別用於列印，一個類別用於保存，一個類別用於通知，以此類推。這簡化了維護工作，減少了團隊之間的衝突，並使版本控制更加容易。
關鍵短語： “將因相同原因發生變化的事物歸為一類，將因不同原因發生變化的事物分開。”
應用SRP的優勢
- 簡化維護： 您確切地知道在哪裡修改程式碼以滿足新的要求。
- 減少衝突： 幾個開發人員可以在不同的領域工作，而不會互相干擾。
- 清理版本控制： 每個類別都反映了與單一職責相關的變化
- 更少的錯誤： 錯誤僅限於相關功能
常見錯誤以及如何避免它們
反覆出現的錯誤是將不同的邏輯（例如，業務邏輯、表示和持久性）混合在一個類別中。解決方案是透過為每個主題創建單獨的課程來劃分工作，儘管這在一開始可能會更加費力。
原則O：開放/封閉（OCP）
此原則指出：「軟體實體應開放擴展，但封閉修改。」其核心思想是允許在不觸及現有程式碼的情況下添加新功能，從而最大限度地降低引入錯誤的風險，並促進系統的演進。
實際上，建議設計類別和模組，以便當需求發生變化或出現新需求時，可以添加擴充（例如，實作介面的新類別），而不是修改經過測試的生產程式碼。
提示：利用介面和抽象類別來實現這一點。這樣，您只需建立新的實作即可開發新功能，而無需擔心破壞現有功能。
例如，在發票系統中，如果需要將發票儲存在不同的位置（文件、資料庫、外部服務等），首先需要定義一個持久化介面。每個新的儲存方法都實作為一個單獨的類，從而避免修改核心邏輯。
應用OCP的要點
- 降低錯誤風險： 經過測試的程式碼庫保持完整
- 促進可擴展性： 系統在複雜性上不會崩潰，但可以成長
- 促進多態性： 您可以在運行時替換或組合實現
請注意，如果將此原則推向極端，可能會適得其反，創建無數沒有明確標準的介面和擴展，導致過度工程。平衡和常識高於一切！
里氏替換原則（LSP）
此原則由芭芭拉·利斯科夫 (Barbara Liskov) 提出，要求子類別必須能夠完全被其基類替換，而不會改變系統的預期功能。
關鍵在於，如果一個方法或函數需要一個基底類別的對象，那麼它也可以處理其子類別的任何對象，而不會出現意外行為或錯誤。
舉個例子：如果你有一個矩形類別和一個正方形子類別（矩形的兩邊相等），那麼適用於矩形的方法也應該可以毫無問題地適用於正方形。如果子類別開始破壞或修改基底類別的約定（例如，以「巧妙」的方式重寫 setter 方法），它就違反了 LSP 原則。
為什麼 LSP 如此重要？
- 安全性： 防止難以偵測的錯誤和意外行為
- 明晰： 確保繼承和多態性的一致性
- 靈活性： 無需重寫或破壞現有程式碼即可擴展系統
原則一：介面隔離原則（ISP）
「許多小而具體的接口比一個單一的、龐大的、通用的接口要好。」ISP 鼓勵定義針對每個需求量身定制的精確接口，而不是強迫所有實現者繼承他們永遠不會使用的方法。
舉個簡單的例子：假設有一個包含付款和預訂功能的停車介面。為了模擬免費停車，你將被迫實現一些你永遠不會使用的付款方式，這會導致不必要的程式碼和混亂。
解決方案在於將介面拆分成幾個更專業的介面：一個用於管理空間，另一個用於支付。這樣，每個類別就只實現它所需要的功能。
從長遠來看，這可以降低複雜性，便於整合新的特定功能，並避免實現中的「噪音」。記住：不必要的依賴項越少，系統就越簡潔，也越容易維護。
原則D：依賴倒置原則（DIP）
或許最深刻的是，這項原則確立了兩個基本規則：
- 高階模組不應該依賴低階模組： 兩者都必須依賴抽象
- 抽像不應該依賴細節，細節應該依賴抽象。
這在實踐中意味著什麼？您的主要元件（例如，業務邏輯控制器）應始終與介面或抽象類別一起工作，而不能直接與特定實作（資料庫、外部服務等）一起工作。因此，如果您明天改變技術或要求，您的核心程式碼幾乎不會改變。
依賴注入是實現這項原則的最佳模式之一。透過這種方式，系統更加靈活、解耦，並且更容易使用模擬或模擬進行測試。
如何在流行語言中應用 SOLID 原則
這些原則並非任何一種語言所獨有。您可以在Java、C#、Python或任何其他物件導向的環境中套用它們。讓我們透過實際範例來看看它們是如何實現的：
Java 中的範例
假設您有一個通知服務。不要直接依賴特定的通知類型，而是建立一個介面並讓不同的實作從中繼承：
public interface NotificationService {
void send(String message);
}
public class EmailNotificationService implements NotificationService {
@Override
public void send(String message) {
// Enviar email
}
}
public class UserController {
private NotificationService notificationService;
public UserController(NotificationService notificationService) {
this.notificationService = notificationService;
}
public void notifyUser() {
notificationService.send("Bienvenido a la inversión de dependencias");
}
}
因此，UserController依賴抽象層，也就是接口，而不是具體的實作。要了解更多關於依賴管理的信息，您可以閱讀有關OpenTitan及其對硬體和軟體安全的影響的文章。
C# 中的範例
public interface IPrinter { void Print(); }
public interface IScanner { void Scan(); }
public class MultifunctionDevice : IPrinter, IScanner {
public void Print() { /* ... */ }
public void Scan() { /* ... */ }
}
這樣，每個介面都是特定的，並且只實現設備所需的部分。
Python 中的範例
class User:
def __init__(self, name):
self.name = name
class UserRepository:
def save(self, user):
# Guardar en la base de datos
pass
class UserNotificationService:
def send_welcome_email(self, user):
# Enviar correo
pass
SOLID 與 Clean Code 之間的關係
編寫整潔程式碼的概念與 SOLID 原則密不可分。編寫整潔程式碼包括使用有意義的名稱、保持方法簡潔且功能集中、減少不必要的複雜性、避免重複以及使軟體結構易於人類閱讀。
事實上，鮑伯大叔自己的著作和文章（例如《程式碼整潔之道：敏捷軟體開發的實用技巧》）都將SOLID原則作為建立真正「整潔」且永續系統的基本指南。如果您想深入了解相關主題，可以參考軟體開發最佳實務。
SOLID 如何幫助清理程式碼？讓軟體的每個部分都易於理解、修改、測試和擴展，避免不必要的註釋，打破複製/貼上的習慣，使任何團隊成員都能更輕鬆地理解程式碼。
實施 SOLID 的優勢和好處
- 易於維護和演進： 以在地化且安全的方式管理變更
- 可擴展性： 該系統可以在功能和開發團隊方面不斷發展，而不會崩潰
- 代碼重用： 組件和模組在不同的環境中使用，避免重複。
- 有效協作： 團隊並行工作，避免關鍵變更重疊的風險
- 錯誤減少： 清晰度和分段可最大限度地減少錯誤的出現並使其更容易定位。
- 可測試性： 分段和解耦的程式碼更容易測試，非常適合單元和整合測試
SOLID 的限制和可能的批評
與任何方法一樣，以過於教條的方式應用 SOLID 可能會導致問題：
- 不必要的複雜性： 過多的介面或碎片化的類別會阻礙開發，尤其是在小型專案中。
- 過度設計： 預測所有可能的擴展最終可能會使簡單的事情變得複雜。
- 學習曲線： 初級開發人員在建立他們的第一個應用程式時可能會感到不知所措。
- 剛性： 在某些情況下，嚴格遵循原則可能會違背所需的敏捷性或效率
關鍵在於運用常識來應用 SOLID 原則：考慮專案的規模、預算和具體情況。在小型應用中，你可能不需要投入大量資源來建立複雜的模式，但你需要理解單一職責的概念，以避免將來出現更大的問題。
何時（以及何時不）應用 SOLID
這些原則是針對需要高可維護性、可擴展性和靈活性的系統而設計的。然而，在某些情況下，嚴格執行這些規定可能會適得其反：
- 小型專案或原型： 優先考慮速度和簡單性，而不是未來的可擴展性
- 新團隊： 逐步推行原則，而不是教條式地推行
- 高性能狀況： 評估添加額外的層是否真的可以彌補
- 遺留系統： 調整遺留程式碼可能需要大量投資；優先考慮漸進式改進
最終，要應用合理的方法，但要記住，過早過度優化可能與缺乏良好實踐一樣有害。
SOLID 與其他原則和模式的關係
除了 SOLID 之外，還有其他補充原則和良好實踐：
- DRY（不要重複自己）： 避免程式碼重複
- KISS（保持簡單，愚蠢）： 保持解決方案簡單
- YAGNI（你不需要它）： 除非真正需要，否則不要實現功能
- 抓牢： 為對象指派職責的模式
將 SOLID 與這些方法結合可以為任何現代物件導向架構帶來多重好處。
在日常生活中採用 SOLID 的實用技巧
- 從小處開始： 首先實現單一職責原則
- 明智地重構： 定期檢查您的程式碼，尋找程式碼異味和改進機會。
- 理論聯繫實務： 根據團隊和專案的實際情況調整原則
- 分享知識： 促進內部辯論、審查和培訓，奠定基礎
請記住，SOLID 原則是指導原則，而不是一成不變的法則。運用這些原則可以改善工作，但當實際情況需要時，不要犧牲實用性或交付速度。
這種方法為開發人員提供了一個堅實的框架，使他們能夠長期創建更強大、更靈活、更易於維護的系統，防止軟體過早老化，並有助於適應不斷變化的市場和業務需求。
