單一職責原則

就一個類而言，應該僅有一個引起它變化的原因。

如果一個類承擔的職責過多，就等於把這些職責耦合在一起，一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。

軟件設計真正要做的許多內容，就是發現職責並把哪些職責相互分離。如果你能夠想到多余一個的動機去改變一個類，那麽這個類就具有多余一個的職責，就應該考慮類的職責分離。

開放-封閉原則

開放-封閉原則，是說軟件實體（類，模塊，函數等）應該可以擴展，但是不可修改。即對擴展開放（Open for extension） ，對更改封閉（Closed for modification）。

軟件需求是一定會變化的，在設計軟件系統的時候遵循開放-封閉原則，當面對需求的變化時，可以相對容易修改，保持相對穩定。

設計軟件要容易維護又不容易出問題的最好辦法，就是多擴展，少修改。

絕對的對修改關閉是不可能的。無論模塊多麽的“封閉”，都會存在一些無法對之封閉的變化。既然不可能完全封閉，設計人員必須對於他設計的模塊應對哪種變化封閉作出選擇。他必須先猜測出最有可能發生的變化種類，然後構造抽象來隔離那些變化。並且，當變化發生時，應當立即采取行動。

在我們最初編寫代碼時，假設變化不會發生。當變化發生時，我們就創建抽象來隔離以後發生的同類變化。

面對需求，對程序的改動是通過增加新代碼進行的，而不是更改現有的代碼。

我們希望的是在開發工作展開不久就知道可能發生的變化。查明可能發生變化所等待的時間越長，要創建正確的抽象就越困難。

開放-封閉原則是面向對象設計的核心所在。遵循這個原則可以帶來面向對下崗技術所聲稱的巨大好處，也就是可維護，可擴展，可復用，靈活性好。開發人員應該僅對程序中呈現出頻繁變化的那些部分作出抽象，然而，對於應用程序中的每個部分都刻意的進行抽象同樣不是一個好主意。拒絕不成熟的抽象和抽象本身一樣重要，避免矯枉過正。

依賴倒轉原則

依賴倒轉原則，主要包括兩點:

• 抽象不應該依賴細節，細節應該依賴於抽象；
• 高層模塊不應該依賴底層模塊，二者都應該依賴抽象；

也就是說針對接口編程，不要對實現編程。例如一個數據庫信息管理系統，數據庫連接屬於低層模塊，增刪改查等操作屬於高層模塊，系統界面屬於更高層的模塊。不同層級的模塊都應該依賴於抽象，也就是接口或者抽象類，只要接口穩定，那麽任何一個的更改都不用擔心其他受影響，這就使得無論高層模塊還是低層模塊都可以很容易地被復用。

裏氏代換原則

子類型必須能夠替換掉它們的父類型。

一個軟件實體如果使用的是一個父類的話，那麽一定適用於其子類，而且它察覺不出父類對象和子類對象的區別。也就是說，把父類都替換成它的子類，程序的行為沒有變化。

例如設計一個鳥類，一個企鵝類，假設鳥類都可以飛，但是企鵝不會飛，那麽企鵝是鳥麽？企鵝可以繼承鳥類嗎？

雖然直觀上企鵝也是一種特殊的鳥類，但是在面向對象編程的世界裏，鳥類會飛，企鵝類不會飛，也就是企鵝類不能以鳥類的身份出現，所以且不能繼承鳥類。

只有當子類可以替換掉父類，軟件單位的功能不受到影響時，父類才能真正被復用，而子類也能夠在父類的基礎上增加新的行為。正是由於子類型的可替換性才使得使用父類類型的模塊在無需修改的情況下就可以擴展。

總結

依賴倒轉可以說是面向對象設計的標誌，用哪種語言來編寫程序不重要，如果便攜式考慮的都是如何針對抽象編程而不是針對細節編程，即程序中所有的依賴關系都是終止於抽象類或者接口，那就是面向對象的設計，反之就是過程化的設計了。

[Python設計模式] 第3～5章 單一職責原則／開放-封閉原則／依賴倒轉原則