關於單一職責原則，我想大家都聽過不少，今天來看看這個原則具體是什麼，有哪些好處使我們需要選擇遵守它呢？
一、定義
乙個類只能因為乙個原因而修改。
怎麼理解呢？簡單來說，乙個類只能實現一項功能，或者換句話說，乙個類只有乙個職責，只有當這個職責發生變化，它才會被修改，
說白了就是乙個類質感乙個類該幹的事。
二、好處
類的複雜性降低
可讀性提高
可維護性提高
變革引起的風險降低
三、難點
難點就在於，有的時候這個職責的劃分是沒有標準答案的，它會根據你專案的大小，時間等一系列的引數而改變，並且乙個類並不是說越小越好，要根據實際情況來定。
四、**示例
下面我們看乙個**，實現乙個「人」類：
**不難，這裡有3個屬性，還有3個方法，ok？
這段**有什麼問題呢？他不符合單一職責原則（並不絕對），為什麼這麼說呢？
因為他將人的屬性和方法封裝在一起了，這樣如果人的屬性增加了，例如增加一項 「膚色"那麼很明顯這個類需要改變；那我增加乙個方法呢，人需要： 」工作「那麼類還需要改變，這是兩個職責，但他都引起類的變化，這是不好的（不能說是不對的）。那我怎麼辦？看下面的**：
乙個人 屬性類
乙個人 方法介面
乙個真正的人 張三
最後是場景類
執行結果：
姓名:張三
我是張三，我愛吃飯
我是張三，我需要解手
我是張三，我愛睡覺
好，上面的**，我增加了乙個人活動介面，具體的人繼承 人類同時實現人類活動的介面。這樣你要增加屬性，我就該person類，如果改變方法，我就該persondo介面就好了。
當然說到這裡，可能就有人會說，p啊，我就覺得人就應該有屬性和方法一起，沒有屬性的人不是人，不會方法的人沒法活，我就要放在一起
咋啦？沒問題，完全可以，應為對於每個人來說，職責是不一樣的，只要不是太大的問題，具體設計由你來定，當然或者說由你的boss定。
設計模式之單一職責原則
首先就名字而言不難想象，單一必定是只能有乙個，而這個乙個指的是什麼呢，那就是乙個職責。而職責通俗易懂來說就是乙個功能，乙個類只能有乙個功能，而如果有兩個及以上的功能就不再符合單一職責原則了。就好比乙個水壺，它的功能就只是裝水，而不存放別的東西，那它就滿足了單一職責原則。優點有複雜度低，或者說簡單明瞭...
設計模式原則 單一職責原則
定義 乙個物件應該只包含單一的職責，並且該職責被完整地封裝在乙個類中。即 不要存在多於乙個導致類變更的原因。通俗的說，就是乙個類只負責一項職責。問題由來 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。解決方案 ...
設計模式原則 單一職責原則
對類來說的，即乙個類應該只負責一項職責。假如類a負責多項職責，當其中一項職責需求發生變更時，可能對其他職責的執行造成影響。例如 類a負責實現 訂單資料持久化 職責 和 使用者資料持久化 職責，那麼當我們需要修改 使用者資料持久化 需求時，由於 糅雜在乙個類裡，可能會對 訂單資料持久化 的職責造成影響...