單一職責原則
前言：據說設計模式是區別程序員與軟件設計師的標准之一。其實在編程學習初期就接觸過設計模式，但是都沒有寫過多少代碼是領悟不到設計模式真正的威力和必要性的。現在自認為也實踐過不少段時間了，是時候總結一下設計模式。不知誰說過沒有寫過十萬行以上代碼別談設計模式，雖然略顯誇張，但是還是很有道理的。只有自己親身經歷過一些編寫設計垃圾代碼，才會深刻理解設計模式真正的意義所在。設計模式都是前輩大牛們在無數次實踐中總結出來的，我輩自然要站在巨人肩膀上，實行拿來主義並消化使用之。今天開始第一啪：設計模式六大原則之單一職責原則。
0、設計模式系列文章
1、問題的由來
初學者在編程的時候可能一開始會有這樣的經歷，使用一個類來實現很多的功能，新添加的甚至不相關的功能都放在一個類里來實現，煮成了一鍋大雜燴，往往使得某個類包羅萬象，無所不能。可能剛開始實現功能比較簡單，這樣做不會引發什么特別大的問題。但是隨着項目復雜度的提升，各種不相關的實現代碼耦合在一起，一旦有功能的更改或增刪，修改的代碼很可能會導致其他功能的正常運行。這種編程方式顯然是不可取的，也就是違背了所謂的單一職責原則。
2、什么是單一職責原則？
單一職責原則的英文名稱是Single Responsibility Principle，簡稱是SRP。SRP原則的解釋是：There should never be more than one reason for a class to change。定義很簡單，即不能存在多於一個導致類變更的原因。簡單的說就是一個類只負責一項職責。
在軟件設計中，秉承着“高內聚，低耦合”的思想，讓一個類僅負責一項職責，如果一個類有多於一項的職責，那么就代表這個類耦合性變高了，這些職責耦合在了一起，這是比較脆弱的設計。因為一旦某一項職責發生了改變，需要去更改代碼，那么有可能會引起其他職責改變。所謂牽一發而動全身，這顯然是我們所不願意看到的，所以我們會把這個類分拆開來，由兩個類來分別維護這兩個職責，這樣當一個職責發生改變，需要修改時，不會影響到另一個職責。
需要說明的是單一職責原則不只是面向對象編程思想所特有的，只要是模塊化的程序設計，都適用單一職責原則。
3、關於職責
看到上面所述，或許有人會說這么簡單誰不知道。的確，很多程序員即使沒有學過設計模式，不知道單一職責原則，在編程的時候，在設計軟件時也會有意識的遵循這一原則。因為誰都不希望修改一個地方會引發另外一個地方出現問題，而避免這種問題的最好處理方式就是設計時遵循單一職責原則。但是，我認為單一職責原則的難點是在於職責范圍的認定。關於職責的認定是一個仁者見仁智者見智的話題，在實際開發中也會引起程序員之間的爭論。有的人認為這些功能方法的實現目的很相似，必須要放在一個類中，有的人認為方法差別很大，必須要分拆成多個類，在多個類里面來實現。
還有職責的擴散問題。軟件一開發完上線后並不是一成不變的，隨着社會的進步，需求的變更，軟件的功能可能要做些維護更改，有時候會遇到職責擴散。所謂的職責擴散就是因為某種原因，職責R被分化為粒度更細的R1和R2。
比如類C只負責一個職責R，這是符合單一職責原則的。但是后來需要把職責R拆分為職責R1和職責R2，那么這時候是否需要死守着單一職責原則，把類C也拆開為C1和C2。接着如果R1又需要細化為R11和R12呢……
我們必須要意識到，一味的遵守單一職責原則，不停的分拆類所付出的開銷是很大的。這時候就涉及到平衡的問題，平衡單一職責原則與修改造成的開銷。我的觀點是如果一個方法邏輯不復雜的情況下，可以修改方法實現，否則要拆分為兩個方法，遵循方法級別的單一職責原則；如果一個類方法不多的情況下，可以只增加方法，而不用分拆為多個類，否則要拆分為多個類，遵循類級別的單一職責原則。
4、遵循單一職責原則的優點
- 降低了類的復雜度。一個類只負責一項職責比負責多項職責要簡單得多。
- 提高了代碼的可讀性。一個類簡單了，可讀性自然就提高了。
- 提高了系統的可維護性。代碼的可讀性高了，並且修改一項職責對其他職責影響降低了，可維護性自然就提高了。
- 變更引起的風險變低了。單一職責最大的優點就是修改一個功能，對其他功能的影響顯著降低。