在設計程式碼中，我們有許多可以依照的設計模式，讓我把整個專案的邏輯結構變得清晰易於維護。當然，在設計模式中我們不只有各種模式，還有許多設計的原則，雖然他們不是程式碼架構的模板，但是這些原則卻時刻提醒我們提高程式碼質量和防止未來麻煩。這次我就將單一職責原則、開放-封閉原則以及依賴倒轉原則進行解釋。

一、單一職責原則

專業解釋：單一職責原則（SRP），就一個類而言，應該僅有一個引起它變化的原因。如果一個類承擔的職責過多，就等於把這些職責耦合在一起，一個職責的變化可能會削弱這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭到意想不到的破壞。

其實很好理解，舉個例子，就像需要寫一個能夠適用於Windows的視覺化介面程式，很多人會將業務邏輯程式碼和介面程式碼混寫在一起，這樣做確實可以將任務完成，但是這樣子會出現一個問題，當我需要一個同樣的能夠在IOS上執行的視覺化介面程式，這個時候我就需要對整個程式進行重構。如果在最開始我就講業務邏輯程式碼和介面程式碼進行分離，那麼當介面程式碼需要變化的時候，就對業務邏輯程式碼影響不大，從而起到了複用的效果。

當然，這樣說起來比做起來容易，軟體設計真正要做的有許多內容，就是發現職責並把那些職責分離，其實去判斷是否分離也不難，那就是如果你能找到多於一個動機去改變這個類，那麼這個類就有多於一個職責。

二、開放-封閉原則

專業解釋：開放-封閉原則，是說軟體實體（類、模組、函式等等），應該可以擴充套件，但是不可以修改。對於擴充套件是是開放的，對於修改是封閉的。

開放-封閉原則給我們的啟發是，如何設計才能面對需求的改變卻可以保持相對穩定，從而可以使系統才在第一個版本以後不斷推出新的版本。這個原則其實和單一職責原則有一定相似的地方，都是將程式儘可能的模組化，降低耦合度，但是開發-封閉原則還強調為以後的擴充套件做準備。就像我們在之前提到過的例子，寫一個計算器程式，最開始的需求只有加減乘除，但以後可能會增加如根號等需求，基於這一點，我們就需要考慮到開放-封閉原則，使用一些方式達到在需求變動的時候，降低我們的工作量，從而我們想到了使用簡單工廠模式。

絕對的對修改關閉是不可能的，無論模組是多麼“封閉”，都會存在一些無法對之封閉的變化，既然不可能完全封閉，設計人員就應該對他設計的模組應該對哪種變化封閉做出選擇，他必須先猜測出最有可能發生的變化種類，然後構造抽象來隔離那些變化。

當然我們不可能在設計程式之初就預測好所有的變化，所以我們在最初編寫程式碼時，假設變化不會發生，當變化發生時，我們就構造抽象來隔離以後發生的同類變化。

開放-封閉原則是面向物件設計的核心所在，遵循這個原則可以帶來面向物件技術所聲稱的巨大的好處，也就是可維護、可擴充套件、可複用、靈活性好，開發人員就應該對程式中出現頻繁變化的那部分做出抽象，然而，對於應用程式中每一個部分刻意的進行抽象並不是一個好主意，拒絕不成熟的抽象和抽象本身一樣重要。

三、依賴倒置原則

專業解釋：高層模組不應該依賴底層模組，兩個都應該依賴抽象。抽象不應該依賴於細節，細節應該依賴抽象。依賴倒置可以說是面向物件設計的標誌，用那種語言來編寫程式不重要，如果編寫時考慮的都是如何針對抽象程式程式設計而不是針對細節程式設計，即程式中所有依賴關係狗屎終止於抽象類或介面，那就是面向物件設計，反之就是過程化設計。

以修電腦為例，更換CPU、記憶體卡等，其實其中就有好幾種面向物件的幾個設計原則。如我們之前講到的單一職責原則，電腦的記憶體壞了，不應該成為更換CPU的理由，他們之間各自的職責很明確，再比如封閉-開放原則，記憶體不夠只要插槽足夠就可以新增，硬碟不夠可以用行動硬碟，PC的介面是有限的，但只要軟體系統設計的好，卻可以無限的擴充套件。而在依賴倒置原則中，抽象不應該依賴細節，細節應該依賴於抽象，說白了就是針對介面程式設計，要對實現程式設計，無論主機板、CPU、硬碟都是針對介面設計的，如果針對現實來設計，那麼在設計主機板CPU等時，就需要知道不同牌子的不同介面。