定義：不要存在多于一個(gè)導(dǎo)致類變更的原因。通俗的說(shuō)，即一個(gè)類只負(fù)責(zé)一項(xiàng)職責(zé)。

問(wèn)題由來(lái)：類T負(fù)責(zé)兩個(gè)不同的職責(zé)：職責(zé)P1，職責(zé)P2。當(dāng)由于職責(zé)P1需求發(fā)生改變而需要修改類T時(shí)，有可能會(huì)導(dǎo)致原本運(yùn)行正常的職責(zé)P2功能發(fā)生故障。

解決方案：遵循單一職責(zé)原則。分別建立兩個(gè)類T1、T2，使T1完成職責(zé)P1功能，T2完成職責(zé)P2功能。這樣，當(dāng)修改類T1時(shí)，不會(huì)使職責(zé)P2發(fā)生故障風(fēng)險(xiǎn)；同理，當(dāng)修改T2時(shí)，也不會(huì)使職責(zé)P1發(fā)生故障風(fēng)險(xiǎn)。

         說(shuō)到單一職責(zé)原則，很多人都會(huì)不屑一顧。因?yàn)樗?jiǎn)單了。稍有經(jīng)驗(yàn)的程序員即使從來(lái)沒(méi)有讀過(guò)設(shè)計(jì)模式、從來(lái)沒(méi)有聽(tīng)說(shuō)過(guò)單一職責(zé)原則，在設(shè)計(jì)軟件時(shí)也會(huì)自覺(jué)的遵守這一重要原則，因?yàn)檫@是常識(shí)。在軟件編程中，誰(shuí)也不希望因?yàn)樾薷牧艘粋€(gè)功能導(dǎo)致其他的功能發(fā)生故障。而避免出現(xiàn)這一問(wèn)題的方法便是遵循單一職責(zé)原則。雖然單一職責(zé)原則如此簡(jiǎn)單，并且被認(rèn)為是常識(shí)，但是即便是經(jīng)驗(yàn)豐富的程序員寫(xiě)出的程序，也會(huì)有違背這一原則的代碼存在。為什么會(huì)出現(xiàn)這種現(xiàn)象呢？因?yàn)橛新氊?zé)擴(kuò)散。所謂職責(zé)擴(kuò)散，就是因?yàn)槟撤N原因，職責(zé)P被分化為粒度更細(xì)的職責(zé)P1和P2。

         比如：類T只負(fù)責(zé)一個(gè)職責(zé)P，這樣設(shè)計(jì)是符合單一職責(zé)原則的。后來(lái)由于某種原因，也許是需求變更了，也許是程序的設(shè)計(jì)者境界提高了，需要將職責(zé)P細(xì)分為粒度更細(xì)的職責(zé)P1，P2，這時(shí)如果要使程序遵循單一職責(zé)原則，需要將類T也分解為兩個(gè)類T1和T2，分別負(fù)責(zé)P1、P2兩個(gè)職責(zé)。但是在程序已經(jīng)寫(xiě)好的情況下，這樣做簡(jiǎn)直太費(fèi)時(shí)間了。所以，簡(jiǎn)單的修改類T，用它來(lái)負(fù)責(zé)兩個(gè)職責(zé)是一個(gè)比較不錯(cuò)的選擇，雖然這樣做有悖于單一職責(zé)原則。（這樣做的風(fēng)險(xiǎn)在于職責(zé)擴(kuò)散的不確定性，因?yàn)槲覀儾粫?huì)想到這個(gè)職責(zé)P，在未來(lái)可能會(huì)擴(kuò)散為P1，P2，P3，P4……Pn。所以記住，在職責(zé)擴(kuò)散到我們無(wú)法控制的程度之前，立刻對(duì)代碼進(jìn)行重構(gòu)。）

舉例說(shuō)明，用一個(gè)類描述動(dòng)物呼吸這個(gè)場(chǎng)景：

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("豬"); 
 } 
} 

運(yùn)行結(jié)果：

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

       程序上線后，發(fā)現(xiàn)問(wèn)題了，并不是所有的動(dòng)物都呼吸空氣的，比如魚(yú)就是呼吸水的。修改時(shí)如果遵循單一職責(zé)原則，需要將Animal類細(xì)分為陸生動(dòng)物類Terrestrial，水生動(dòng)物Aquatic，代碼如下：

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("魚(yú)"); 
 } 
} 

運(yùn)行結(jié)果：

牛呼吸空氣
羊呼吸空氣
豬呼吸空氣
魚(yú)呼吸水

我們會(huì)發(fā)現(xiàn)如果這樣修改花銷是很大的，除了將原來(lái)的類分解之外，還需要修改客戶端。而直接修改類Animal來(lái)達(dá)成目的雖然違背了單一職責(zé)原則，但花銷卻小的多，代碼如下：

class Animal{ 
  public void breathe(String animal){ 
    if("魚(yú)".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("魚(yú)"); 
  } 
} 

        可以看到，這種修改方式要簡(jiǎn)單的多。但是卻存在著隱患：有一天需要將魚(yú)分為呼吸淡水的魚(yú)和呼吸海水的魚(yú)，則又需要修改Animal類的breathe方法，而對(duì)原有代碼的修改會(huì)對(duì)調(diào)用“豬”“牛”“羊”等相關(guān)功能帶來(lái)風(fēng)險(xiǎn)，也許某一天你會(huì)發(fā)現(xiàn)程序運(yùn)行的結(jié)果變?yōu)椤芭：粑绷?。這種修改方式直接在代碼級(jí)別上違背了單一職責(zé)原則，雖然修改起來(lái)最簡(jiǎn)單，但隱患卻是最大的。還有一種修改方式：

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("魚(yú)"); 
  } 
} 

        可以看到，這種修改方式?jīng)]有改動(dòng)原來(lái)的方法，而是在類中新加了一個(gè)方法，這樣雖然也違背了單一職責(zé)原則，但在方法級(jí)別上卻是符合單一職責(zé)原則的，因?yàn)樗](méi)有動(dòng)原來(lái)方法的代碼。這三種方式各有優(yōu)缺點(diǎn)，那么在實(shí)際編程中，采用哪一中呢？其實(shí)這真的比較難說(shuō)，需要根據(jù)實(shí)際情況來(lái)確定。我的原則是：只有邏輯足夠簡(jiǎn)單，才可以在代碼級(jí)別上違反單一職責(zé)原則；只有類中方法數(shù)量足夠少，才可以在方法級(jí)別上違反單一職責(zé)原則；

        例如本文所舉的這個(gè)例子，它太簡(jiǎn)單了，它只有一個(gè)方法，所以，無(wú)論是在代碼級(jí)別上違反單一職責(zé)原則，還是在方法級(jí)別上違反，都不會(huì)造成太大的影響。實(shí)際應(yīng)用中的類都要復(fù)雜的多，一旦發(fā)生職責(zé)擴(kuò)散而需要修改類時(shí)，除非這個(gè)類本身非常簡(jiǎn)單，否則還是遵循單一職責(zé)原則的好。
遵循單一職責(zé)原的優(yōu)點(diǎn)有：

• 可以降低類的復(fù)雜度，一個(gè)類只負(fù)責(zé)一項(xiàng)職責(zé)，其邏輯肯定要比負(fù)責(zé)多項(xiàng)職責(zé)簡(jiǎn)單的多；
• 提高類的可讀性，提高系統(tǒng)的可維護(hù)性；
• 變更引起的風(fēng)險(xiǎn)降低，變更是必然的，如果單一職責(zé)原則遵守的好，當(dāng)修改一個(gè)功能時(shí)，可以顯著降低對(duì)其他功能的影響。
  

        需要說(shuō)明的一點(diǎn)是單一職責(zé)原則不只是面向?qū)ο缶幊趟枷胨赜械?，只要是模塊化的程序設(shè)計(jì)，都適用單一職責(zé)原則。

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評(píng)論