設計原則與軟體設計

眾所周知，設計原則是設計模式的基石。當遵循設計原則的時候，寫出的代碼就會變得非常靈活，並且可以應對變化，也更加容易維護。當然，也不是那麼絕對。下面首先會簡要介紹一些基本的設計原則，然後再介紹Robert C. Martin的S.O.L.I.D原則。

1 設計原則簡述

KISS原則（Keep It Simple Stupid）

軟體開發中常常遇到的問題就是：把一個問題過度的複雜化。KISS原則的目的就是提倡在設計和編碼中，盡量保持代碼的簡約，避免不必要的複雜。簡約不等於簡單。

DRY原則（Don’t Repeat Yourself）

DRY原則的目的就是：抽取系統中的公用部分，並把它放置在一個地方以避免重複。這個原則不只是適用於代碼中，而且也可以用於功能和商務邏輯上，確保不重複。這就要求對系統的職能有良好的分割，每個功能之間有著清晰的界限，用例之間不存在交叉。

Tell，Don’tAsk

這個原則是與封裝有關的，要求對代碼進行合理的封裝，並把它們放到正確的類中。同時這個原則也指出：必須明確告訴對象：我們想要它們去執行什麼樣的操作，而不是首先詢問對象的狀態，然後我們自己決定去執行什麼操作。

YAGNI原則（You Ain’tGonna Need It）

YAGNI原則指出：系統中只包含所必須的功能，不要包含你認為將來可能會用到的功能或者特性，防止過度設計。這個原則在TDD中體現得比較完全。在TDD中，首先寫出代表系統必須功能的測試案例，然後再實現系統的功能代碼，然後進行測試，直至測試代碼通過。

SoC原則（Separation Of Concerns）

SoC就是把一個軟體功能分離為單獨功能點。被分離的每個功能點有唯一的行為和資料，而且每個功能點都能夠被其他所需要的類單獨使用。通過這個原則，我們可以最大限度地實現代碼重用、功能重用、模組重用。

講述了一些基本的設計原則之後，再來看看Bob在《敏捷式軟體開發 (Agile Software Development)設計》[1]一書中提到的五個原則，簡稱S.O.L.I.D原則。

S.O.L.I.D原則融合了基本的原則，並且提出了更加具有可操作性的方法。

SRP（Single Responsibility Principle ）

單一職責原則：就一個類而言，應該僅有一個引起它變化的原因。如果一個類承擔的職責過多，就等於把這些職責都耦合在一起了。一個職責的變化可能會削弱或抑制這個類完成其他職責的能力。這個原則，不僅僅適用於類的設計上，還適用於介面以及模組的設計上。

OCP（Open-Closed Principle）

開放-封閉原則：軟體實體（類，模組等）應該是可以擴充的，但是不可修改。只有在設計和開發中遵守OCP原則，才能避免在新加功能之後產生連鎖反應。OCP關注的是靈活性：功能的改動是通過增加代碼進行的，而不是修改現有的代碼。一般來說，OCP是通過融合ISP（介面分離原則）和建立抽象來隔離後面同類型的變化的，LSP（裡氏替換原則）使得這個目標成為可能。

LSP（Liskov Substitution Principle）

裡氏替換原則：子類型必須能夠替換掉它們的基底類型。

ISP（Interface Segregation Principle）

介面分離原則：不應該強迫類實現它不需要的方法。如果一個介面中包含了很多不大而且不相關的方法，那麼這個介面就必須要被分組，然後分離成多個介面，讓實現介面的類只是去實現它所需要的方法。同時這也體現了在設計中，要盡量遵從SRP（單一職責原則）。

DIP（Dependency Inversion Principle）

依賴倒置原則：高層的模組不應該依賴於低層的模組，二者都應該依賴於抽象；抽象不應該依賴於細節，細節應該依賴於抽象。高層模組是指系統不經常發生變化的部分，是一個系統區別於其他系統的重要標誌，它包含了系統的策略選擇與業務模型。低層模組是指系統中經常發生變化的部分。