🧑‍💻 SOLID 原則，程式設計的結構安全規範

寫程式就像蓋大樓，初期可能只是一層樓，隨便加幾根柱子就能站得住。但隨著需求增加，樓層越蓋越高，如果沒有良好的設計規範，整棟大樓可能會因為一個小改動而搖搖欲墜。程式設計也是如此，隨著系統規模擴大，程式碼容易變得難以維護。為了避免「改一行壞三行」的情況，Robert C. Martin（Uncle Bob）提出了 SOLID 原則，成為軟體工程師設計架構的重要基石。

📌 SOLID 五大原則

1. S — Single Responsibility Principle (單一職責原則) 一個類別應該只有一個改變的理由。好處是降低耦合，讓程式碼更容易測試與維護。
2. O — Open/Closed Principle (開放封閉原則) 對擴展開放，對修改封閉。好處是可以新增功能而不必改動既有程式碼，降低風險。
3. L — Liskov Substitution Principle (里氏替換原則) 子類別必須能替代父類別使用。好處是確保繼承結構合理，避免「矩形不能替代正方形」的錯誤。
4. I — Interface Segregation Principle (介面隔離原則) 應該建立多個小而專注的介面，而不是一個龐大介面。好處是避免類別被迫實作不需要的方法。
5. D — Dependency Inversion Principle (依賴反轉原則) 高層模組不應依賴低層模組，兩者都應依賴抽象。好處是降低依賴，讓系統更容易測試與替換。

📖 比喻

可以把 SOLID 想像成 建築設計的五大安全規範：

• 單一職責：每根柱子只承擔一個方向的重量。
• 開放封閉：可以加建樓層，但不用拆掉原有結構。
• 里氏替換：不同材質的磚頭都能替代使用。
• 介面隔離：每個房間有獨立的電源開關，而不是一個總開關控制全部。
• 依賴反轉：建築師依賴設計圖，而不是直接依賴工人手法。

📖 案例

假設你要設計一個「訂單系統」：

• 違反 SRP：同一個類別同時處理訂單建立、付款、寄送，修改一個功能可能影響其他功能。
• 應用 OCP：新增「電子支付」功能，只需擴展付款模組，不必修改原有程式。
• 應用 LSP：信用卡付款類別能替代一般付款類別使用，不會破壞邏輯。
• 應用 ISP：寄送介面只包含「寄送」方法，不強迫付款模組去實作。
• 應用 DIP：高層的「訂單服務」依賴抽象的「付款介面」，而不是具體的「信用卡付款類別」。

📖 為什麼重要

• 提升可維護性：程式碼更容易修改與擴展。
• 降低風險：避免修改一個功能導致其他功能出錯。
• 團隊合作更順暢：不同人負責不同模組，邊界清晰。

🎯 結語

SOLID 原則不是要你死記硬背，而是幫助你在設計程式時保持清晰結構。它就像建築規範，讓系統能穩固成長。

👉一句話總結：SOLID 原則是程式設計的「結構安全規範」，幫助程式碼保持簡潔、可擴展、可維護，讓系統能隨需求成長而不崩壞。