單一職責原則：就乙個類而言，應該僅有乙個引起它變化的原因。如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意向不到的破壞。比如說俄羅斯方塊遊戲，考慮哪些是介面，哪些是邏輯，然後封裝成不同的類。
軟體設計真正要做的許多內容就是發現職責並把那些職責相互分離，如何判斷是否應該分離出類來，就是考慮下是否有多於乙個的動機去改變乙個類，那麼這個類就有多於乙個的職責。
開放-封閉原則：軟體實體（類、模組、函式等）應該可以擴充套件，但是不可修改。也就是說對擴充套件開放，對更改封閉。
在研發一開始，需求會一直變化，怎樣的設計才能面對需求的改變卻可以保持相對的穩定，從而使系統可以在第乙個版本以後不斷推出新的版本。最好的方法就是多擴充套件、少修改。但是，絕對的對修改關閉是不可能的，無論模組是多麼封閉，都會發生一些對之無法封閉的變化，既然不可能完全封閉，設計人員必須對於他設計的模組應該對那種變化無法封閉做出選擇，他必須猜測最有可能發生的變化種類，然後構造抽象來隔離那些變化。
又或者初次未想清楚，後來發生了變化，那麼當變化發生時，我們就建立抽象來隔離以後發生的同類變化。
開放-封閉原則是物件導向設計的核心所在。遵循這個原則可以帶來物件導向技術所聲稱的巨大好處，也就是可維護、可擴充套件、可服用和靈活性好。開發人員應該僅對程式中呈現出頻繁變化的那部分作出抽象，然而對於應用程式中每個部分都刻意進行抽象同樣不是乙個好主意。拒絕不成熟的抽象和抽象本身一樣重要。
設計模式原則 單一職責原則
定義 乙個物件應該只包含單一的職責，並且該職責被完整地封裝在乙個類中。即 不要存在多於乙個導致類變更的原因。通俗的說，就是乙個類只負責一項職責。問題由來 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。解決方案 ...
設計模式原則 單一職責原則
對類來說的，即乙個類應該只負責一項職責。假如類a負責多項職責，當其中一項職責需求發生變更時，可能對其他職責的執行造成影響。例如 類a負責實現 訂單資料持久化 職責 和 使用者資料持久化 職責，那麼當我們需要修改 使用者資料持久化 需求時，由於 糅雜在乙個類裡，可能會對 訂單資料持久化 的職責造成影響...
設計模式原則 單一職責原則
1.概念 對類來說的，即乙個類應該只負責一項職責。如類a負責兩個不同職責 職責1，職責2。當職責1需求變更而改變a時，可能造成職責2執行錯誤，所以需要將類a的粒度分解為a1，a2。2.問題的提出 package com.atguigu.principle.singleresponsibility p...