1.單一職責原則
單一職責原則：就乙個類而言，應該僅有乙個因其他變化的原因。
如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，當乙個職責變化的可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。
軟體設計真正要做的許多內容，就是發現職責並把那些職責相互分離，
2.開放-封閉原則
開放-封閉原則：是說軟體實體（類，模組，函式等等）應該可以擴充套件，但是不可修改。
無論乙個模組是多麼的「封閉」，都會存在一些變化，既然不可能完全封閉，設計人員必須對他設計的模組應該對哪種變化封閉做出選擇，他必須先猜測最有可能發生的變化種類，然後構造抽象來隔離那些變化。
面對需求，對程式的改動是通過新增新的**來實現，而不是去更改現有的**。這就是開放-封閉原則的精神所在。
遵循這個原則可以帶來物件導向技術所聲稱的巨大好處，也就是可維護，可擴充套件，可復用，靈活性好。開發人員應僅對程式中呈現的頻繁變化的那部分做出抽象，然而，對於應用程式中每個部分都刻意進行抽象同樣不是乙個好主意。拒絕不成熟的抽象和抽象本身就是一樣重要的。
3.依賴倒轉原則
a：高層模組不依賴底層模組。兩個都應該依賴抽象
b：抽象不應該依賴細節。細節應該依賴抽象
應該面向介面程式設計，不要對實現程式設計。
4.狄公尺特法則
也叫最少知識原則：如果兩個類不必彼此直接通訊，那麼這兩個類就不應當發生直接的相互作用。如果其中乙個類需要呼叫另乙個類的某乙個方法的話，可以通過第三者**這個呼叫
在類的結構設計上，每乙個類應該盡量降低成員的訪問許可權。狄公尺特發展其根本思想，是強調類之間的鬆散耦合。
本文使用blog_backup未註冊版本匯出，請到soft.pt42.com註冊。
設計模式時的相關原則
開閉原則 open closed principle ocp software entities should be open for extension,but closed for modification.這個模組可以在不被修改的前提下被擴充套件。不修改源 而改變模組的行為 例如 策略模式 黎...
設計模式中的設計原則
最近在看 head first 設計模式 先一步一步總結點知識。設計原則 含義 開 閉 原則 ocp 軟體實體應當對擴充套件開放，對修改關閉，即軟體實體應當在不修改的前提下擴充套件。黎克特制代換原則 lsp 父類能出現的地方都可以替換為子類，但反之不一定。單一職責原則 srp 乙個類只負責一項職責。...
設計模式中的原則
近階段在研讀設計模式，設計模式中最重要的一部分就是設計原則，單獨將這一部分拿出來深入 和研究 0 開閉原則 修改關閉，拓展開放。當程式需要變化滿足新需求的時，盡量不要在原有基礎上修改，而是拓展程式 便於程式的維護 拓展和公升級 使用介面和抽象類可以滿足這樣的需求。1 單一職責原則 每個類應該實現單一...