英文名稱：single responsibility principle 簡稱srp
中文名稱：單一職責原則
作用：1、類的複雜性降低，實現什麼職責都有清晰明確的定義（這都是廢話）
2、可讀性提高（同樣也是廢話，複雜性降低了，可讀性難道還會不高）
3、變更引起的風險降低，變更是必不可少的，如果介面的單一職責做的好，乙個介面修改只對相應的實現類有影響，對其他的接
口無影響（這個也是應該的，本來乙個類可以實現的，結果搞這麼多類出來，應該主要就是為了降低變更風險）
理解與實踐：
說實在的，在不知道這個srp設計模式之前，很多類的設計原則也差不多是按照這個來設計的，舉個最簡單的例子，使用者管理中設計中，一般都是將使用者的屬性與行為分成兩個類來實現，乙個是userinfo類，主要是用來處理使用者屬性的，另外乙個usercontroller類，主要用來處理使用者行為的，這樣將屬性和行為分開的行為應該就是符合spr的行為準則了吧！
從讀書時候開始一直都熱愛使用rose來畫uml圖，但是rose缺乏.net方面的雙向工程，所以選擇了enterprise architect來實現uml圖，先看看我在系統裡是如何實現這兩個常用的類的吧，實際些**的時候會把userinfo做為乙個物件傳遞。
上面的這個例子實在太簡單，一般人都會這樣做，那麼對於稍微複雜一點的類，這個職責該如何判斷呢？又如撥打**的類：打**、聊天、掛**，那麼這個放在乙個類中合適嗎？其實仔細想想，打**和掛**是屬於協議管理，而聊天則屬於資料傳輸管理，而資料傳輸則有很多種方式，為了避免今後資料傳輸的不斷變更，最好是將聊天從**類中分離出來，設計好的uml圖如下：
l、蟻后：有生殖能力的雌性，或稱母蟻，在群體中體型最大，特別是腹部大，***官發達，觸角短，胸足小，有翅、脫翅或無翅。主要職責是產卵、繁殖後代和統管這個群體大家庭。
2．雄蟻：或稱父蟻。頭圓小，上顎不發達，觸角細長。有發達的***官和外***，主要職能是與蟻后交配。
3．工蟻：又稱職蟻。無翅，一般為群體中最小的個體，但數量最多。複眼小，單眼極微小或無。上顎、觸角和三對胸足都很發達，善於步行奔走。工蟻是沒有生殖能力的雌性。工蟻的主要職責是建造和擴大巢穴、採集食物、伺喂幼蟻及蟻后等。
4．兵蟻：頭大，上顎發達，可以粉碎堅硬食物，在保衛群體時即成為戰鬥的**。
太神奇了，我們的大自然都嚴格遵守這種單一職責原則，只有單一職責原則，才能夠讓事情更加輕鬆，才能夠單個看起來簡單，聯合起來力量確實非常之神奇。
設計的uml圖如下所示：
我再想想我現在的工作呢？我的工作任務好像非常的不符合單一職責原則，加入那次我的老大問我，我的類的劃分是否都是按照單一職責原則劃分的，我是否可以反問他：請問我的工作職責是不是按照單一職責原則劃分的呢？哈哈，有點意思！
設計原則 單一職責原則
定義 不要存在多於乙個導致類變更的原因。通俗的說，即乙個類只負責一項職責。問題由來 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。解決方案 遵循單一職責原則。分別建立兩個類t1 t2，使t1完成職責p1功能，t...
設計原則 單一職責原則
1 原則的定義 2 原則設計的初衷 3 能解決哪些問題 4 有哪些場景可以使用 單一職責原則，英文名single responsibility principle,縮寫為srp。乙個類或者模組只負責完成乙個職責 或者功能 也就是說，不要設計大而全的類，要設計粒度小，功能單一的類。換個角度來講就是，乙...
設計原則 單一職責原則
在物件導向程式設計領域中，單一職責原則 single responsibility principle 規定每個類都應該有乙個單一的功能，並且該功能應該由這個類完全封裝起來。所有它的 這個類的 服務都應該嚴密的和該功能平行 功能平行，意味著沒有依賴 乙個類或者模組應該有且只有乙個改變的原因。乙個具體...