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

定義：不要存在多於一個致使類變動的緣由。通俗的說，即一個類只負責一項職責。

問題由來：類T負責兩個不一樣的職責：職責P1，職責P2。當因爲職責P1需求發生改變而須要修改類T時，有可能會致使本來運行正常的職責P2功能發生故障。

解決方案：遵循單一職責原則。分別創建兩個類T一、T2，使T1完成職責P1功能，T2完成職責P2功能。這樣，當修改類T1時，不會使職責P2發生故障風險；同理，當修改T2時，也不會使職責P1發生故障風險。

      說到單一職責原則，不少人都會不屑一顧。由於它太簡單了。稍有經驗的程序員即便歷來沒有讀過設計模式、歷來沒有據說過單一職責原則，在設計軟件時也會自覺的遵照這一重要原則，由於這是常識。在軟件編程中，誰也不但願由於修改了一個功能致使其餘的功能發生故障。而避免出現這一問題的方法即是遵循單一職責原則。雖然單一職責原則如此簡單，而且被認爲是常識，可是即使是經驗豐富的程序員寫出的程序，也會有違背這一原則的代碼存在。爲何會出現這種現象呢？由於有職責擴散。所謂職責擴散，就是由於某種緣由，職責P被分化爲粒度更細的職責P1和P2。

      好比：類T只負責一個職責P，這樣設計是符合單一職責原則的。後來因爲某種緣由，也許是需求變動了，也許是程序的設計者境界提升了，須要將職責P細分爲粒度更細的職責P1，P2，這時若是要使程序遵循單一職責原則，須要將類T也分解爲兩個類T1和T2，分別負責P一、P2兩個職責。可是在程序已經寫好的狀況下，這樣作簡直太費時間了。因此，簡單的修改類T，用它來負責兩個職責是一個比較不錯的選擇，雖然這樣作有悖於單一職責原則。（這樣作的風險在於職責擴散的不肯定性，由於咱們不會想到這個職責P，在將來可能會擴散爲P1，P2，P3，P4……Pn。因此記住，在職責擴散到咱們沒法控制的程度以前，馬上對代碼進行重構。）

舉例說明，用一個類描述動物呼吸這個場景：

1 2 3 4 5 6 7 8 9 10 11 12 13

class Animal {      public void breathe ( String animal ) {          System . out . println ( animal + "呼吸空氣" ) ;      } } public class Client {      public static void main ( String [ ] args ) {          Animal animal = new Animal ( ) ;          animal . breathe ( "牛" ) ;          animal . breathe ( "羊" ) ;          animal . breathe ( "豬" ) ;      } }

運行結果：

牛呼吸空氣
羊呼吸空氣
豬呼吸空氣

      程序上線後，發現問題了，並非全部的動物都呼吸空氣的，好比魚就是呼吸水的。修改時若是遵循單一職責原則，須要將Animal類細分爲陸生動物類Terrestrial，水生動物Aquatic，代碼以下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

class Terrestrial {      public void breathe ( String animal ) {          System . out . println ( animal + "呼吸空氣" ) ;      } } class Aquatic {      public void breathe ( String animal ) {          System . out . println ( animal + "呼吸水" ) ;      } }   public class Client {      public static void main ( String [ ] args ) {          Terrestrial terrestrial = new Terrestrial ( ) ;          terrestrial . breathe ( "牛" ) ;          terrestrial . breathe ( "羊" ) ;          terrestrial . breathe ( "豬" ) ;                   Aquatic aquatic = new Aquatic ( ) ;          aquatic . breathe ( "魚" ) ;      } }

 

運行結果：

牛呼吸空氣
羊呼吸空氣
豬呼吸空氣
魚呼吸水

咱們會發現若是這樣修改花銷是很大的，除了將原來的類分解以外，還須要修改客戶端。而直接修改類Animal來達成目的雖然違背了單一職責原則，但花銷卻小的多，代碼以下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

class Animal {      public void breathe ( String animal ) {          if ( "魚" . equals ( animal ) ) {              System . out . println ( animal + "呼吸水" ) ;          } else {              System . out . println ( animal + "呼吸空氣" ) ;          }      } }   public class Client {      public static void main ( String [ ] args ) {          Animal animal = new Animal ( ) ;          animal . breathe ( "牛" ) ;          animal . breathe ( "羊" ) ;          animal . breathe ( "豬" ) ;          animal . breathe ( "魚" ) ;      } }

能夠看到，這種修改方式要簡單的多。可是卻存在着隱患：有一天須要將魚分爲呼吸淡水的魚和呼吸海水的魚，則又須要修改Animal類的breathe方法，而對原有代碼的修改會對調用「豬」「牛」「羊」等相關功能帶來風險，也許某一天你會發現程序運行的結果變爲「牛呼吸水」了。這種修改方式直接在代碼級別上違背了單一職責原則，雖然修改起來最簡單，但隱患倒是最大的。還有一種修改方式：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

class Animal {      public void breathe ( String animal ) {          System . out . println ( animal + "呼吸空氣" ) ;      }        public void breathe2 ( String animal ) {          System . out . println ( animal + "呼吸水" ) ;      } }   public class Client {      public static void main ( String [ ] args ) {          Animal animal = new Animal ( ) ;          animal . breathe ( "牛" ) ;          animal . breathe ( "羊" ) ;          animal . breathe ( "豬" ) ;          animal . breathe2 ( "魚" ) ;      } }

 

       能夠看到，這種修改方式沒有改動原來的方法，而是在類中新加了一個方法，這樣雖然也違背了單一職責原則，但在方法級別上倒是符合單一職責原則的，由於它並無動原來方法的代碼。這三種方式各有優缺點，那麼在實際編程中，採用哪一中呢？其實這真的比較難說，須要根據實際狀況來肯定。個人原則是：只有邏輯足夠簡單，才能夠在代碼級別上違反單一職責原則；只有類中方法數量足夠少，才能夠在方法級別上違反單一職責原則；

       例如本文所舉的這個例子，它太簡單了，它只有一個方法，因此，不管是在代碼級別上違反單一職責原則，仍是在方法級別上違反，都不會形成太大的影響。實際應用中的類都要複雜的多，一旦發生職責擴散而須要修改類時，除非這個類自己很是簡單，不然仍是遵循單一職責原則的好。

遵循單一職責原的優勢有：

• 能夠下降類的複雜度，一個類只負責一項職責，其邏輯確定要比負責多項職責簡單的多；
• 提升類的可讀性，提升系統的可維護性；
• 變動引發的風險下降，變動是必然的，若是單一職責原則遵照的好，當修改一個功能時，能夠顯著下降對其餘功能的影響。

      須要說明的一點是單一職責原則不僅是面向對象編程思想所特有的，只要是模塊化的程序設計，都適用單一職責原則。