內容摘錄自《大話設計模式》
單一職責原則，就乙個類而言，應該僅有乙個引起它變化的原因
如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。
例如，介面與遊戲邏輯就應該進行分離，當要改變介面時，不過是窗體類的變化，和遊戲邏輯無關，以此達到復用的目的。
軟體設計真正要做的許多內容，就是發現職責並把那些職責相互分離。
開放-封閉原則，是說軟體實體（類、模組、函式等等）應該可以擴充套件，但是不可修改。對於擴充套件是開放的，對於更改是封閉的。
無論模組是多麼的『封閉』，都會存在一些無法對之封閉的變化。既然不可能完全封閉，設計人員必須對於他設計的模組應該對哪種變化封閉做出選擇。他必須先猜測出最有可能發生的變化種類，然後構造抽象來隔離那些變化。
一般來說很難預先猜測可能會發生的變化，但我們卻可以在發生小變化時，就及早去想辦法應對發生更大變化的可能。
依賴倒轉原則
a．高層模組不應該依賴低層模組。兩個都應該依賴抽象。
b．抽象不應該依賴細節。細節應該依賴抽象。
把pc電腦理解成是大的軟體系統，任何部件如cpu、記憶體、硬碟、顯示卡等都可以理解為程式中封裝的類或程式集，由於pc易插拔的方式，不管哪乙個出問題，都可以在不影響別的部件的前提下進行修改或替換。
這種易插拔，在物件導向裡面就叫強內聚、松耦合。
例如cpu的對外都是針腳式或觸點式等標準的介面，cpu只需要把介面定義好，內部再複雜也不讓外界知道，而主機板只需要預留與cpu針腳的插槽就可以了。
單一職責原則，就修電腦來說，顯然記憶體壞了，不應該成為更換cpu的理由，它們各自的職責是明確的。
開發-封閉原則，記憶體不夠只要插槽足夠就可以新增，硬碟不夠可以用行動硬碟等，pc的介面是有限的，所以擴充套件有限，軟體系統設計得好，卻可以無限地擴充套件。
依賴倒轉原則，說白了，就是要針對介面程式設計，不要對實現程式設計。無論主機板、cpu、記憶體、硬碟都是在針對介面設計的，如果針對實現來設計，記憶體就要對應到具體的某個品牌的主機板，那就會出現換記憶體需要把主機板也換了的尷尬。
為什麼叫倒轉？
面向過程的開發時，為了使得常用**可以復用，一般都會把常用**寫成函式的程式庫，這樣我們在做新專案時，去呼叫這些低層的函式就可以了。比如我們做的專案要訪問資料庫，就把訪問資料庫的**寫成了函式，每次做新專案時就去呼叫這些函式。這也就叫做高層模組依賴低層模組。
問題也就出在這裡，我們要做新專案時，發現業務邏輯的高層模組都是一樣的，但客戶卻希望使用不同的資料庫或儲存資訊方式，這時就出現麻煩了。我們希望能復用這些高層模組，但高層模組與低層的訪問資料庫是繫結在一起的，沒辦法復用。
就想剛才說的，pc裡如果cpu、記憶體、硬碟都需要依賴具體的主機板，主機板一壞，所有的部件就都沒用了，這顯然不合理。反過來，如果記憶體壞了，也不應該造成其他部件不能用才對。而如果不管高層模組還是低層模組，它們都依賴於抽象，具體一點就是介面或抽象類，只要介面是穩定的，那麼任何乙個的更改都不用擔心其他受到影響，這就使得無論高層模組還是低層模組都可以很容易的被復用。
為什麼依賴了抽象的介面或抽象類，就不怕更改呢？這就要說到黎克特制代換原則了。
黎克特制代換原則
黎克特制代換原則：子型別必須能夠替換掉它們的父型別。
白話翻譯就是乙個軟體實體如果使用的是乙個父類的話，那麼一定適用於其子類，而且它察覺不出父類物件和子類物件的區別。也就是說，在軟體裡面，把父類都替換成它的子類，程式的行為沒有變化。
正因為有了這個原則，使得繼承復用成為了可能，只有當子類可以替換掉父類，軟體單位的功能不受到影響時，父類才能真正被復用，而子類也能夠在父類的基礎上增加新的行為。
比方說，貓是繼承動物類的，以動物的身份擁有吃、喝、跑、叫等行為，可等某一天，我們需要狗、牛、羊也擁有類似的行為，由於它們都是繼承於動物，所以除了更改例項化的地方，程式其他處不需要改變。
對於開放-封閉原則來說，正是由於子型別的可替換性才使得使用父類型別的模組在無需修改的情況下就可以擴充套件。
單一職責原則和開放 封閉原則
如果設計乙個計算器有加減乘除的功能。下面的uml圖違反了什麼原則 單一職責原則 就乙個類而言，應該僅有乙個引起它變化的原因。產生原因 如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意...
設計模式 單一職責原則 開放 封閉原則
乙個產品簡單一些,職責單一一些,或許是更好的選擇.單一職責原則,就乙個類而言,應該僅有乙個引起它變化的原因.如果乙個類承擔的職責過多,就等於把這些職責耦合在一起,乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力.這種耦合會導致脆弱的設計,當發生變化時,設計會遭受到意想不到的破壞.軟體設計真正...
設計模式之單一職責原則 開放 封閉原則
單一職責原則 1.單一職責定義 就乙個類而言，應該僅有乙個引起它變化的原因。通俗的說，即乙個類只負責一項職責。問題描述 類 t負責兩個不同的職責 職責 p1，職責 p2。當由於職責 p1需求發生改變而需要修改類 t時，有可能會導致原本執行正常的職責 p2功能發生故障。如果乙個類承擔職責過多，就等於把...