單一職責原則（SRP : Single Response Principle)就一個類而言，應該僅有一個引起它變化的原因。
在這里，職責的定義是： “變化的原因”。對于何時遵循SRP有以下的考慮：
1.如果應用程序的變化會影響到類中某一種職責，那么就應該將它與另一種職責分開，這樣做可以避免客戶應用程序和類中的這兩職責耦合在一起。
2.如果應用程序的變化總是會導致兩個職責同時變化，那么就不必要分離它們。實際上，分離它們會引起不必要的復雜性。
從上可以得知：變化的軸線僅當變化實際發生時才具有真正的意義。如果沒有征兆，那么去應用SRP，或者任何其它原則都是不明智。
實際應用：持久化（Persistence）實
際開發中，考慮到業務規則是會頻繁改變的，而持久化的方式卻不會如此頻繁的變化，并且變化的原因也是完全不同的。如果把業務規則和持久化方式綁定到一起，
就會為以后的開發、維護造成麻煩。運用分層（layer）架構模式或者TDD開發方式可以很早分離這兩個職責，特殊情況下，還可以使用FACADE或者
PROXY模式對設計進行重構，分離這兩個職責。
開閉原則（OCP : The Open-Close Principle)
描述：軟件實體（類、模型、函數等等）應該是可以擴展的，但是不可修改。
遵循開閉原則設計出的模塊具有兩個主要的特征。它們是：
1. “對于擴展是開放的”（Open for extension）。
這意味著模塊的行為是可以擴展的。當應用的需要改變時，我們可以對模塊進行擴展，使其具有滿足那些改變的新行為。換句話說，我們可以改變模塊的功能。
2. “對于更改是封閉的”（Closed for modification）。
對模塊行為進行擴展時，不必改動模塊的源代碼或者二進制代碼。模塊的二進制可執行版本，無論是可鏈接的庫、DLL或者Java的.jar文件，都無需改動。
對于OCP，關鍵的是 抽象
模塊可以操作一個抽象體。由于模塊依賴于一個固定的抽象體，所以它對于更改可以是關閉的。同時，通過從這個抽象體派生，也可以擴展此模塊的行為。
在許多方面，OCP都是面向對象設計的核心所在。但實際應用中，濫用OCP原則也是錯誤的。正確的做法是應該僅僅對程序中呈現出頻繁變化的那些部分做出抽象。拒絕不成熟的抽象和抽象本身一樣重要。
Liskov替換原則（LSP）
描述：子類型（subtype）必須能夠替換掉它們的基類型（base type）。
此原則是Barbara Liskov首次在1988年寫下的。所以就叫做Liskov替換原則。她如此寫到：
“這里需要如下替換性質：若對每個類型S的對象o1，都存在一個類型T的對象o2，使得在所有針對T編寫的程序P中，用o1替換o2后，程序P行為功能不變，則S是T的子類型。
LSP然我們得出一個非常重要的結論：一個模型，如果孤立的看，并不具有真正意義上的有效性。模型的有效性只能通過它的客戶程序來表現。
在考慮一個特定設計是否恰當時，不能完全孤立的來看這個解決方案。必須要根據該設計的使用者所做出的合理假設來審視它。
有
誰知道設計的使用者會做出什么樣的合理假設呢？大多數這樣的假設都很難預測。事實上，如果試圖去預測所有這些假設，我們所得到的系統很可能會充滿不必要的
復雜性的臭味。因此，像所有其它原則一樣了，通常最好的辦法就是只預測那些最明顯的對于LSP的違反情況，而推遲所有其它的預測，直到出現相關的脆弱性的
臭味時，才去處理它們。
IS-A是關于行為的。
LSP清晰的指出，OOD中IS－A關系是就行為方式而言的，行為方式是可以進行合理假設的，是客戶程序所依賴的。
基于契約設計
基
于契約設計（DBC：Design By
Contract）。使用DBC，類的編寫者能夠顯式的規定針對該類的契約?？蛻舸a的編寫者可以通過該契約獲悉可以依賴的行為方式。契約是通過為每個方
法聲明的前置條件（preconditions)和后置條件（postconditions)來指定的。要使一個方法得以執行，前置條件必須要為真。執行
完畢后，該方法要保證后置條件為真。
在單元測試中指定契約
也可以通過編寫單元測試的方式來指定契約?？蛻舸a編寫者會去查看這些單元測試，這樣他們就可以知道對于要使用的類，應該做什么合理的假設。
啟發式規則和習慣用法
1.派生類中的退化函數
在基類中實現了f()方法，在派生類中的函數f()就是退化的，派生類中的退化函數并不總表示為違反LSP，但是當存在這種情況時，還是值得注意一下的。
2.從派生類中拋出異常
在派生類的方法中添加了其基類不會拋出的異常。如果基類的使用者不期望這些異常，那么把它們添加到派生類的方法中就會導致不可替換性。此時要遵循LSP，要么就必須改變使用者的期望，要么派生類就不應該拋出這些異常。
總
結：OCP是OOD中很多原則的核心。如果這個原則應用的有效，應用程序就會具有更多的可維護性、可重用性以及健壯性。LSP是使OCP成為可能的主要原
則之一。正是子類型的可替換性才使得使用基類類型的模塊在無需修改的情況下就可以擴展。這種可替換性必須是開發人員可以隱式依賴的。因此，如果沒有顯式的
強制基類類型的契約，那么代碼就必須良好的并且明顯的表達出這一點。
術語IS-A的含義過于廣泛以至于不能作為子類型的定義。子類型的正確定義是“可替換性”，這里的可替換性可以通過顯式或者隱式的契約來定義。