如果設計乙個計算器有加減乘除的功能。下面的uml圖違反了什麼原則：
單一職責原則：就乙個類而言，應該僅有乙個引起它變化的原因。
產生原因：如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。
判斷方法：如果你能想到多於乙個的動機去改變乙個類，那麼這個類就具有多於乙個的職責。如上圖，我們修改加法，減法，都要修改這個運算類，這就違反了單一職責原則。
所以我們可以構造出加減乘除的類。讓這個運算類，只有乙個引起它變化的原因。軟體設計真正要做的許多內容，就是發現職責並把那些職責相互分離。
開放-封閉原則：是說軟體實體（類，模組，函式等等）應該可以擴充套件，但是不可修改。
特徵：1.對於擴充套件是開放的。2.對於更改是封閉的。
優點：面對需求的改變可以保持相對穩定，使系統可以不斷更新。
方法：構造抽象隔離變化。面對需求，對程式的改動是通過增加新**進行的，而不是更改現有的**。
遵循這個原則可以帶來物件導向技術所聲稱的巨大好處，也就是可維護，可擴充套件，可復用，靈活性好。開放人員應該僅對程式中呈現出頻繁變化的那些部分做出抽象，對於應用程式中的每個部分都可以地進行抽象同樣不是乙個好主意。拒絕不成熟的抽象和抽象本身一樣重要。
我們可以構造抽象運算類來隔離變化，讓運算類封閉，禁止更改。下面的加減乘除類開放，可以擴充套件，新增新的功能。例如新增開平方根這個類，只需要把開平方根寫成子類，繼承運算類即可，從而保持穩定。
所以我們可以更改上面為：
設計模式 單一職責原則 開放 封閉原則
乙個產品簡單一些,職責單一一些,或許是更好的選擇.單一職責原則,就乙個類而言,應該僅有乙個引起它變化的原因.如果乙個類承擔的職責過多,就等於把這些職責耦合在一起,乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力.這種耦合會導致脆弱的設計,當發生變化時,設計會遭受到意想不到的破壞.軟體設計真正...
設計模式之單一職責原則 開放 封閉原則
單一職責原則 1.單一職責定義 就乙個類而言，應該僅有乙個引起它變化的原因。通俗的說，即乙個類只負責一項職責。問題描述 類 t負責兩個不同的職責 職責 p1，職責 p2。當由於職責 p1需求發生改變而需要修改類 t時，有可能會導致原本執行正常的職責 p2功能發生故障。如果乙個類承擔職責過多，就等於把...
單一職責 開放 封閉 依賴倒轉原則
內容摘錄自 大話設計模式 單一職責原則，就乙個類而言，應該僅有乙個引起它變化的原因 如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。例如，介面與遊戲邏輯就應該進行分離，...