以下內容來自《敏捷軟體開發-原則、模式與實踐》
ood設計原則
srp，單一職責原則：就乙個類而言，應該僅有乙個引起它變化的原因
· 將過多的職責耦合在乙個類中導致了脆弱設計
· 職責是變化的原因
· 如果應用程式變化的方式總是導致兩個職責同時變化，則不應該分離他們
· 把業務規則和持久化子系統繫結在一起是自討苦吃，這違反了單一職責原則。可以使用 facade 或者 proxy 模式進行重構，以解除這種耦合
· 軟體設計真正要做的許多內容，就是發現職責並把那些職責相互分離
ocp，開放封閉原則：軟體實體（類、模組、函式等等）應該是可擴充套件的，但是不可修改的
· 任何系統在其生命週期內都回變化
· 變化應該是導致新增新的**，而不是修改已經正常執行的**
· ocp的關鍵是抽象
· 介面和客戶的關係要比實現它的類和客戶的關係更密切
· 策略模式和模板模式是用以滿足ocp的最常用方法
· 沒有對於所有情況都貼切的模型，也即不可能完全封閉，所以應該預先猜測出最有可能的變化種類
· 拒絕不成熟的抽象和抽象本身一樣重要
lsp，liskov可替換原則：子型別必須能夠替換它們的基型別
· 對於lsp的違反也潛在的違反了ocp
· 正方形從長方形繼承的例子微妙的違反了這種原則
· 在考慮乙個特定的設計是否恰當時，不能孤立地來看這個解決方案，必須根據設計的使用者所做出的合理假設來審視它
· 物件的行為方式是軟體真正所關注的問題， is a 關係是就行為而言的
· 派生類只能使用相等或更弱的前置條件來替換原始的前置條件，只能使用相等或更強的前置條件來替換原始的後置條件。
· 完成的功能少於基類的派生類通常不能替換基類，也不符合lsp
· 派生類不應該丟擲基類不能預計的異常，否則違反lsp
dip，依賴倒置原則：高層模組不應該依賴於底層模組，二者都應該依賴於抽象
· 抽象不應該依賴於細節，細節應該依賴於抽象
· 所有結構良好的物件導向架構都具有清晰的層次定義，每個層次通過乙個定義良好的受控介面向外提供一組內聚的服務
· 乙個物件持有另外乙個具體物件的引用可能破壞了dip
· 策略不應該依賴於細節，細節和策略都應該依賴於抽象
· 如果依賴關係是倒置的，那麼就是物件導向的設計，否則就是過程化的設計。
isp，介面隔離原則：不應該強迫客戶依賴於他們不用的方法，將不同的介面分離，而不是集合
· 如果強迫客戶程式依賴於那些他們不使用的方法，那麼這些客戶程式就面臨著由於這些未使用方法的改變而帶來的變更。
· 使用委託分離介面
· 使用多重整合分離介面
OOD設計原則之OCP LSP
一直談軟體設計，卻不能準確的描述。結合最近看 黑客與畫家 這才對設計的六大原則有了一點淺顯的體會。首先說一下乙個專案的路徑 開發 重構 測試 投產 運維。其中重構的好處就是希望對原有設計和 進行修改 注意 重構的應該分兩個方向 設計上的修改和 上的修改 而運維則是希望儘量減少對原有 的修改，保持歷史...
OOD設計原則之開閉原則（OCP）
開閉原則ocp open close principle 被稱作是ood的基石，是ood最重要的原則之一。這個原則由大師bertrand meyer在1988年提出 汗，那個時候恐怕國內還很少人知道oo，甚至計算機為何物 software entities should be open for ex...
OOD設計原則之開閉原則（OCP）
開閉原則ocp open close principle 在維基百科的定義 在物件導向程式設計中，開閉原則規定 軟體中的物件 類，模組，函式等等 應該對擴充套件是開放的，但是對於修改是封閉的 這意味著乙個實體是允許在不改變他的源 的前提下變更他的行為。勃蘭特丶梅耶一般被認為是最早提出開閉原則這一術語...