引用的3篇部落格，都很詳細的例子，這篇部落格是通過對參考內容的總結，便於自己理解，例子可以看參考的3篇部落格，這裡不寫

什麼是單一職責原則

單一職責原則：就一個類而言，應該僅有一個引起它變化的原因  簡單記憶：術業有專攻，我是專門搬磚的！！                         

怎麼理解這句話：

大話設計模式這本書這樣寫：

如果一個類承擔的職責過多，就等於把這些職責耦合在一起，一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。

個人是這樣理解的：

一個開發工程師相當於一個類，這個團隊只有它一個人（類），ui是他設計，前端是他開發，後端也是他，運維也是他的，所有

職責都是他，那麼他做一個專案會做到完美嗎，一定會顧此失彼的。這時，我們用單一職責解放這個苦逼的程式設計師，只讓他幹後端開發，（一個類只有引起它變化的原因）。其他的開發工作交給其他人，將職責相互分離。

為什麼要使用單一職責原則

首先，單一職責原則是程式設計常識，最好遵守，不要讓麻煩主動找咱。

他的優點：

總的來說：使用單一職責原則：

從概念上就能看出：1.一個類一個職責，是不是維護起來很方便，需要改哪個就改哪個，不用擔心改了其他的。

                               2.擴充套件起來也方便，一個人一個坑，不容易搞錯。既然一個人一個坑，複用起來也方便。我就只要你這個

                              功能，其他的我不要，是不是複用性強。

• 可以降低類的複雜度，一個類只負責一項職責，其邏輯肯定要比負責多項職責簡單的多；
• 提高類的可讀性，提高系統的可維護性；
• 變更引起的風險降低，變更是必然的，如果單一職責原則遵守的好，當修改一個功能時，可以顯著降低對其他功能的影響。