設計模式六大設計原則（一）：單一職責原則

什麼是單一職責原則

單一職責原則的原話是：

There should never be more than one reason for a class to change。

翻譯過來就是應該有且僅有一個緣由引發類的變動。

要知道，咱們的方法、接口、類都是基於職責設計的，只是粒度不一樣，單一職責原則，強調的是咱們的方法、接口、類不該該包含太多的職責。

爲何要實現單一職責原則

1. 最重要的一點，是由於須要儘可能控制職責變化形成不可控的大範圍的變化。下降變動風險，若是一個方法包含的職責過多，那麼只要其中一個職責變化，咱們就須要修改方法，可是修改方法原則上來講咱們須要確保全部調用者的指望返回不會受影響。但是若是方法職責過多，那麼基於需求變更，方法修改的頻率也會增多，同時另外一方面方法影響的調用者也比實現了單一職責的方法範圍大，這回對咱們維護帶來很大的麻煩。同理，接口、類包含的職責過多，弊端也是如此。
2. 加強了可讀性。由於方法、接口、類都是對代碼的封裝，對於使用者來講不須要了解其內部實現。單一職責使得咱們看到這個方法、接口、類的引用時咱們就明確的知道了使用者的意圖，想使用什麼職責而不至於深刻去看內部實現。

實踐中的痛點

1. 實踐中最最重要的痛點是我不知道怎麼劃分這個職責啊，方法的職責粒度該是什麼，接口的職責粒度該是什麼，類的職責粒度該是什麼。
2. 職責粒度劃分的越細，編寫時類和代碼量都會增多。

關於如何劃分職責粒度的建議

基於需求變更的預判考慮

基於實際需求的變化可能性程度本身判斷，職責劃分的粒度取決於需求的粒度，若是一個職責預判會根據需求常常發生改變，那麼這個職責應該被獨立出來。

按方法、接口、類粒度從小到大進行控制

其次對於方法、接口、類實現單一職責的原則，對職責劃分粒度排序應該是方法>接口>類。方法粒度最小能夠理解，由於方法屬於接口或類，接口排在類前面是由於咱們在實際編程當中是面向接口編程，方法的入參出參都是接口，只有在方法內部實現的時候是採用實例實現接口。因此接口粒度要求比類要嚴格一些（兩個擁有各自職責的接口能夠由一個類來實現）。

基於可讀性考慮

考慮是否職責的進一步劃分會使得代碼可讀性提升，封裝以後，只看外部引用，不看內部細節，是否能一目瞭然。