設計模式原則（一）--- 單一職責原則
單一職責原則
單一職責原則（Single Responsibility Principle），簡稱SRP。
其實在日常生活中，單一職責是隨處可見的。
- 數碼相機的拍照功能
- 音響放歌
在貼近一些我們程式猿生活的
- 做顯示處理的顯示卡
- 做聲音處理的音效卡
從以上幾點出發。可以看出，每個人或者物品分別處理著一個功能，並且在處理自己的領域時，都有著頂級的能力。
- 我們知道，對於數碼相機的拍照功能和音響放歌的功能，我們日常生活中的手機都具備著他們兩個的能力。但在單獨一個能力表現上都不如它們。
手機並不能拍出數碼相機的清晰度，也不能放出與音響的3D效果。所以對於數碼相機音響來說，單一的功能才可以有更強的實力。 - 同理，cpu 也有整合的顯示卡和音效卡，但是為了用到看到更好的畫質，我們增加了顯示卡。為了更好的音效增加了音效卡。顯示卡音效卡在僅有的功能上體現了更強大的實力。
這就是我們要了解的單一職責原則
為什麼使用
在開發中我們也需要經常使用到單一職責原則，為了以後更好的維護以及擴充套件。
如果一個類承擔的責任過多，就等於把這些職責耦合在一起，一個職責的變化可能會消弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。
軟體設計真正要做的許多內容，就是發現職責並把那些職責相互分離
那麼我們什麼時候才需要使用呢？
如果你能夠想到多於一個的動機去改變一個類，那麼這個類就具有多於一個的職責就一個類而言，應該僅有一個引起它變化的原因。
應用場景
對於我們經常使用的工具類，如 Json 解析工具類，http 請求工具類，加密解密工具類。
我們都可以將它們看作單一職責。
我們不要誤解 http 請求有 post 請求和 get 請求等。
它擁有多個職責或者說功能。這樣的錯誤理解是把功能看的細節化。
我們必須站在對應的高度來看待某一個類的功能。不可高也不可低。
例如開發中的 DAO 層。
我們可以說增刪改查的每個方法都是單一職責。
也可以說一個類處理所有的表的增刪該查。這個類的單一職責就是處理資料庫表的操作。
應該合理的分解為，一個表一個類。這個類就是處理這個表的單一職責。也是我們開發生涯中常用的。
在日常開發中，我們經常操作的就是 service 服務層。
而服務層的單一職責的設計起到整個專案維護的難易程度，也是最難分離職責的地方。
我們開發時經常把很多功能放在一個 service 裡面。導致修改一個功能會左找右找，或者改很多地方。
所以高度的定位是我們未來要通過不斷實踐來決定的。
單一職責原則在生活中無處不在。
有問題或者喜歡的歡迎評論。
轉載請註明出處！！！！！！
參考資料
《大話設計模式》