單一職責原則
1.
單一職責定義：
就乙個類而言，應該僅有乙個引起它變化的原因。通俗的說，即乙個類只負責一項職責。
問題描述：類
t負責兩個不同的職責：職責
p1，職責
p2。當由於職責
p1需求發生改變而需要修改類
t時，有可能會導致原本執行正常的職責
p2功能發生故障。
如果乙個類承擔職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者抑制這個類其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受意想不到的破壞。
解釋說明：
比如：類
t只負責乙個職責
p，這樣設計是符合單一職責原則的。後來由於某種原因，也許是需求變更了，也許是程式的設計者境界提高了，需要將職責
p細分為粒度更細的職責p1，
p2，這時如果要使程式遵循單一職責原則，需要將類
t也分解為兩個類t1和
t2，分別負責p1、
p2兩個職責。但是在程式已經寫好的情況下，這樣做簡直太費時間了。所以，簡單的修改類
t，用它來負責兩個職責是乙個比較不錯的選擇，雖然這樣做有悖於單一職責原則。（這樣做的風險在於職責擴散的不確定性，因為我們不會想到這個職責
p，在未來可能會擴散為p1，
p2，p3，
p4……pn
。所以記住，在職責擴散到我們無法控制的程度之前，立刻對**進行重構）
開放
-封閉原則
1. 開放-
封閉原則定義：
軟體實體
(類、模組、函式等
)可以擴充套件，不可修改。對於擴充套件是開放的，對於更改是封閉的。
2.
解釋說明：
該原則意思就是說，當設計的時候，時刻考慮好，讓這個類足夠好，寫好了就不要去修改，當有新的需求，增加一些類，原來的**則不改動。
本文參考網上部落格及大話設計模式總結。
設計模式 單一職責原則 開放 封閉原則
乙個產品簡單一些,職責單一一些,或許是更好的選擇.單一職責原則,就乙個類而言,應該僅有乙個引起它變化的原因.如果乙個類承擔的職責過多,就等於把這些職責耦合在一起,乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力.這種耦合會導致脆弱的設計,當發生變化時,設計會遭受到意想不到的破壞.軟體設計真正...
單一職責原則和開放 封閉原則
如果設計乙個計算器有加減乘除的功能。下面的uml圖違反了什麼原則 單一職責原則 就乙個類而言，應該僅有乙個引起它變化的原因。產生原因 如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意...
單一職責 開放 封閉 依賴倒轉原則
內容摘錄自 大話設計模式 單一職責原則，就乙個類而言，應該僅有乙個引起它變化的原因 如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。例如，介面與遊戲邏輯就應該進行分離，...