了解設計模式的朋友們，想必都聽說過「六大設計原則」吧。其實最經典的 23 種設計模式中或多或少地都在使用這些設計原則，也就是說，設計模式是站在設計原則的基礎之上的。所以在學習設計模式之前，很有必要對這些設計原則先做一下了解。
gof（四人幫），傳說中的四位大神們，他們聯手搞出了一套設計模式，堪稱 ood（物件導向設計）的經典之作！震驚了整個軟體開發領域。但這四個老傢伙非常怪異，總是喜歡顯擺一些高深的理論，甚至有時候不說人話，十分讓人費解。
除了最經典的六大設計原則以外，還有一些其他的設計原則也非常重要，本文會一起列舉，不斷收集，不斷更新。
永遠不應該有多於乙個原因來改變某個類。
對於乙個類而言，應該僅有乙個引起它變化的原因。說白了就是，不同的類具備不同的職責，各施其責。這就好比乙個團隊，大家分工協作，互不影響，各做各的事情。
當我們做系統設計時，如果發現有乙個類擁有了兩種的職責，那就問自己乙個問題：可以將這個類分成兩個類嗎？如果真的有必要，那就分吧。千萬不要讓乙個類幹的事情太多！
軟體實體，如：類、模組與函式，對於擴充套件應該是開放的，但對於修改應該是封閉的。
簡言之，對擴充套件開放，對修改封閉。換句話說，可以去擴充套件類，但不要去修改類。
當需求有改動，要修改**了，此時您要做的是，盡量用繼承或組合的方式來擴充套件類的功能，而不是直接修改類的**。當然，如果能夠確保對整體架構不會產生任何影響，那麼也沒必要搞得那麼複雜了，直接改這個類吧。
使用基類的指標或引用的函式，必須是在不知情的情況下，能夠使用派生類的物件。
父類能夠替換子類，但子類不一定能替換父類。也就是說，在**中可以將父類全部替換為子類，程式不會報錯，也不會在執行時出現任何異常，但反過來卻不一定成立。
在繼承類時，務必重寫（override）父類中所有的方法，尤其需要注意父類的 protected 方法（它們往往是讓您重寫的），子類盡量不要暴露自己的 public 方法供外界呼叫。
該原則由麻省理工學院的 barbara liskov 女士提出，她是美國第一位獲取計算機博士學位的女性，曾經也獲得過計算機圖靈獎。
儘量減少物件之間的互動，從而減小類之間的耦合。簡言之，一定要做到：低耦合，高內聚。
在做系統設計時，不要讓乙個類依賴於太多的其他類，需盡量減小依賴關係，否則，您死都不知道自己怎麼死的。
該原則也稱為「迪公尺特法則（law of demeter）」，由 ian holland 提出。這個人不太願意和陌生人說話，只和他走得最近的朋友們交流。
乙個類與另乙個類之間的依賴性，應該依賴於盡可能小的介面。
不要對外暴露沒有實際意義的介面。也就是說，介面是給別人呼叫的，那就不要去為難別人了，盡可能保證介面的實用性吧。她好，我也好。
當需要對外暴露介面時，需要再三斟酌，如果真的沒有必要對外提供的，就刪了吧。一旦您提供了，就意味著，您將來要多做一件事情，何苦要給自己找事做呢。
高層模組不應該依賴於低層模組，它們應該依賴於抽象。抽象不應該依賴於細節，細節應該依賴於抽象。
應該面向介面程式設計，不應該面向實現類程式設計。面向實現類程式設計，相當於就是論事，那是正向依賴（正常人思維）；面向介面程式設計，相當於通過事物表象來看本質，那是反向依賴，即依賴倒置（程式設計師思維）。
並不是說，所有的類都要有乙個對應的介面，而是說，如果有介面，那就盡量使用介面來程式設計吧。
將以上六大原則的英文首字母拼在一起就是 solid（穩定的），所以也稱之為 solid 原則。
只有滿足了這六大原則，才能設計出穩定的軟體架構！但它們畢竟只是原則，只是四人幫給我們的建議，有些時候我們還是要學會靈活應變，千萬不要生搬硬套，否則只會把簡單問題複雜化，切記！
二、補充設計原則
當要擴充套件類的功能時，優先考慮使用組合，而不是繼承。這條原則在 23 種經典設計模式中頻繁使用，如：**模式、裝飾模式、介面卡模式等。可見江湖地位非常之高！
當 a 模組依賴於 b 模組，b 模組依賴於 c 模組，c 依賴於 a 模組，此時將出現迴圈依賴。在設計中應該避免這個問題，可通過引入「中介者模式」解決該問題。
應該將易變的類放在同乙個包裡，將變化隔離出來。該原則是「開放-封閉原則」的延生。
如果重用了包中的乙個類，那麼也就相當於重用了包中的所有類，我們要盡可能減小包的大小。
好萊塢明星的經紀人一般都很忙，他們不想被打擾，往往會說：don't call me, i'll call you. 翻譯為：不要聯絡我，我會聯絡你。對應於軟體設計而言，最著名的就是「控制反轉」（或稱為「依賴注入」），我們不需要在**中主動的建立物件，而是由容器幫我們來建立並管理這些物件。
三、其他設計原則
1. 不要重複你自己（don't repeat yourself - dry）
不要讓重複的**到處都是，要讓它們足夠的重用，所以要盡可能地封裝。
2. 保持它簡單與傻瓜（keep it ****** and stupid - kiss）
不要讓系統變得複雜，介面簡潔，功能實用，操作方便，要讓它足夠的簡單，足夠的傻瓜。
3. 高內聚與低耦合（high cohesion and low coupling - hclc）
模組內部需要做到內聚度高，模組之間需要做到耦合度低。
4. 慣例優於配置（convention over configuration - coc）
盡量讓慣例來減少配置，這樣才能提高開發效率，盡量做到「零配置」。很多開發框架都是這樣做的。
5. 命令查詢分離（command query separation - cqs）
在定義介面時，要做到哪些是命令，哪些是查詢，要將它們分離，而不要揉到一起。
6. 關注點分離（separation of concerns - soc）
將乙個複雜的問題分離為多個簡單的問題，然後逐個解決這些簡單的問題，那麼這個複雜的問題就解決了。難就難在如何進行分離。
7. 契約式設計（design by contract - dbc）
模組或系統之間的互動，都是基於契約（介面或抽象）的，而不要依賴於具體實現。該原則建議我們要面向契約程式設計。
8. 你不需要它（you aren't gonna need it - yagni）
不要一開始就把系統設計得非常複雜，不要陷入「過度設計」的深淵。應該讓系統足夠的簡單，而卻又不失擴充套件性，這是其中的難點。
軟體設計原則
開閉原則 ocp 軟體設計的最大原則 這個原則說的是 對擴充套件開放，對修改關閉。其實意思是說，給系統新增新的功能，但不修改原有 如果能做到呢，關鍵在於抽象化，也就是封裝變化，抽象層不變，讓具體實現依賴抽象隨需求變化。使得系統具有很強的擴充套件性和可維護性。黎克特制代換原則 任何基類可以出現的地方，...
軟體設計原則
高內聚 低耦合 乙個軟體系統要有乙個穩定的架構，不會隨需求的改變而發生巨大的變動。因此，高內聚 低耦合是乙個軟體系統設計中必須遵循的基本原則 面向抽象程式設計 在面向過程的軟體開發中，上層元件呼叫下層元件，就意味著上層元件依賴於下層元件，當下層元件發生劇烈變化時，上層元件也要跟著一起發生變動，這將導...
軟體設計原則
軟體開發中有以下一些基本原則，深刻掌握這些原則比掌握一門技術要重要。1.開閉原則 open closed principle,ocp 乙個軟體應當對擴充套件開放，對修改關閉。也就是說我們在設計軟體時，應當可以在不必修改源 的情況下改變 擴充套件 其行為。開閉原則是非常重要的設計原則，其它的設計原則實...