# 物件導向設計中常見的設計原則
###### tags: `Design Patterns` `book`

90年代，Java語言的問世及應用，帶動了使用物件導向程式語言(OOPL)進行軟體設計的潮流。所以，在軟體分析與設計領域之中，陸續出現了針對使用OOPL進行軟體設計時，所需搭配的「設計原則」。這些原則指導著軟體設計者，在進行軟體實作時應該要注意的事項及應該避免的情況。

如果軟體設計者能夠充分了解這些原則並加以應用，就可以讓他實作出來的軟體系統更加穩定、容易維護、並具有轉移性。 Robert Cecil Martin在其著作《Agile Software Development: Principles, Patterns, and Practices》中，將常見的設計原則做了清楚的說明，包含了下列五個設計原則：

* [單一職責原則(SRP: Single Responsibility Principle)](/3wPFcY4qTSOC700bkY9HOg)
* [開放封閉原則(OCP: Open-Closed Principle)](/85Dq0Rm5Sjm4ody1I2j8Lg)
* [里氏替代原則(LSP: Liskov Substitution Principle)](/0kbQZ0MERJKr4EIhv4D91Q)
* [相依性反向原則(DIP: Dependence Inversion Principle)](/ifX_r7nPTwmxHBrHbKkUSQ)
* [介面分割原則(ISP: Interface Segregation Principle)](/iyDBp1CiQPOn3PNT2p6Rkg)
* [最少知識原則(LKP: Least Knowledge Principle)](/qUFClSLpQmSUuiSwSd2-OA)

除了最少知識原則(LKP)之外，剛好字首五個字母組合在一起就成為了`SOLID`。`SOLID`是Robert. C. Martin提出的五個物件導向設計。

然而`SOLID`原則就是物件導向開發的指導方針，引導出物件導向的優點以及程式碼所隱含的缺點。但這不代表物件導向沒有缺點，要是濫用`SOLID`原則所帶來的傷害會遠超乎想像。

## SOLID 原則的好處？

當SOLID 原則導入到專案內，複雜的程式碼會大量的簡化，提高程式碼的可讀性。降低閱讀程式碼所需要的時間，對程式設計工程師無疑是一件好事，將時間及精力花費在新增及修改上。

SOLID 原則是邁向資深工程師的必備觀念，幾乎所有軟體開發的進階觀念都建構在良好的物件導向程式碼之上。Uncle Bob在書中說過：

> 我的書裡所教的觀念與技巧，都只對乾淨的 Code 有效益。如果你的程式碼還很雜亂，請先學會怎麼整理程式碼。 - Uncle Bob

SOLID 原則是踏入資深工程師階段的必學觀念。幾乎所有 軟體開發的進階觀念，都建構在良好的物件導向程式碼之上。要是沒辦法妥善運用物件導向，就沒辦法運用軟體開發的進階觀念/技巧。

》這相當重要，若工程師沒有能力學習進階觀念，很可能就會一直停留在碼農階段。

但是學會 SOLID 原則之後呢？
以下列出 SOLID 未來的應用，下列被提及的每個議題都是 進階物件導向重要的基石，很值得花時間投資：

1. 單元測試
- 用程式碼撰寫測試程式，取代手動測試。
- 替專案提供回歸測試，時時刻刻執行單元測試，檢查有沒有人改壞程式碼。
- 符合 SOLID 原則的程式碼可以輕易導入單元測試。
2. 重構
- 在不改變程式碼外部行為的前提下，修改程式碼內部的結構，提升可讀性與擴充性。
- 重構必然會搭配測試，避免改壞程式碼。
- 低階重構：把爛 Code 重構成符合物件導向 SOLID 原則（敏捷開發）。
- 中階重構：把 SOLID 重構成設計模式（敏捷開發）。
- 高階重構：把 SOLID 重構成軟體架構（敏捷開發）。
3. 設計模式
- 進階物件導向應用
- 學習物件與物件之間常見的組合模式。用來管理程式碼的複雜度，或解決開發系統中的各種常見問題。
- 學過設計模式，在寫程式或閱讀程式的時候，會用更高一層的視角去思考。
- 最後會培養出根深蒂固的抽象觀念。