設計模式-單一職責原則
單一職責原則使用的是建立型模式
建立型模式對類進行抽象
重點，建立型模式能夠將物件的建立和和物件的使用分離。即使用建立型模式能夠使得物件的建立，物件的使用分離。重點在於分離。設計模式有六大基本原則，單一職責原則，黎克特制替換原則，依賴倒置原則，介面隔離原則，迪公尺特法則，開閉原則。
其中建立型模式符合單一職責原則。
即srp 使用者角色管理等模組，使用的是rbac模型
rbac 一種以角色為儲存的控制，使用rbac 不賦予許可權，賦予角色，例如windows的使用者管理，使用的是賦予角色，對使用者進行管理，這種方式為rbac，目的在於使得使用者和許可權分離。設計乙個使用者管理，依據單一職責模型，設計以下的結構。
該結構定義一些管理使用者的，增加使用者的一些內容，寫入乙個介面中，然後進行實現。
該介面具有以上的問題。
使用者的屬性（是否為註冊使用者，vip使用者等等），使用者的行為（增加使用者，刪除使用者）沒有分開。
該介面一團糟！
應該使用者的資訊，使用者的行為抽取為乙個介面，然後乙個介面繼承這兩個介面
更改的如下所示
why? 為什麼要分離，因為單一職責原則，當使用單一職責原則的時候，每個介面，每個類需要承擔單一的職責，不應該承擔過多的原則，易於維護
核心 ，乙個介面只有乙個原則！乙個介面只能負責一件事情，只有乙個原因能引起其變化
這個介面包含兩個職責，協議管理和資料傳送。
dial和chat為通話，該通話和撥打**，使用了同時都和協議有關係，如果要更改協議，那麼這兩個介面的內容都需要進行更改。由於乙個介面存在兩個職責，所以該介面需要劃分為兩個介面
此時存在乙個關聯關係，撥打**和協議的實現，兩者之間存在關聯關係，此關聯關係為靜態關聯這個類圖完全符合單一職責的原則。每個狀態只決定一件事情。每個狀態的更改只改變一件事情。
好處 複雜度降低 可讀性提高 可維護性增強 變更引起的風險降低（因為變更的時候如果每個介面只負責乙個單一的原則，那麼乙個介面的修改對其他沒有影響，這樣降低了整體的複雜度）
刀就是刀，叉就是叉，1就是1,0就是0.沒有中間態，每個方法也同樣的適用於單一原則，每個方法也同樣的只承擔乙個內容。乙個作用。
this is sometimes hard to see
這個有時候很難說！
對介面盡量做到單一原則，類的做到引起乙個原因引起的變化。
www.iming.info
設計模式原則 單一職責原則
定義 乙個物件應該只包含單一的職責，並且該職責被完整地封裝在乙個類中。即 不要存在多於乙個導致類變更的原因。通俗的說，就是乙個類只負責一項職責。問題由來 類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...