這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)什么實(shí)現(xiàn)Java項(xiàng)目中的單一職責(zé)原則,文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述,閱讀完這篇文章希望大家可以有所收獲。
創(chuàng)新互聯(lián)專注于企業(yè)成都全網(wǎng)營銷推廣、網(wǎng)站重做改版、鎮(zhèn)沅網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、html5、成都做商城網(wǎng)站、集團(tuán)公司官網(wǎng)建設(shè)、外貿(mào)營銷網(wǎng)站建設(shè)、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計(jì)等建站業(yè)務(wù),價(jià)格優(yōu)惠性價(jià)比高,為鎮(zhèn)沅等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。定義:不要存在多于一個(gè)導(dǎo)致類變更的原因。通俗的說,即一個(gè)類只負(fù)責(zé)一項(xiàng)職責(zé)。
問題由來:類T負(fù)責(zé)兩個(gè)不同的職責(zé):職責(zé)P1,職責(zé)P2。當(dāng)由于職責(zé)P1需求發(fā)生改變而需要修改類T時(shí),有可能會導(dǎo)致原本運(yùn)行正常的職責(zé)P2功能發(fā)生故障。
解決方案:遵循單一職責(zé)原則。分別建立兩個(gè)類T1、T2,使T1完成職責(zé)P1功能,T2完成職責(zé)P2功能。這樣,當(dāng)修改類T1時(shí),不會使職責(zé)P2發(fā)生故障風(fēng)險(xiǎn);同理,當(dāng)修改T2時(shí),也不會使職責(zé)P1發(fā)生故障風(fēng)險(xiǎn)。
說到單一職責(zé)原則,很多人都會不屑一顧。因?yàn)樗唵瘟恕I杂薪?jīng)驗(yàn)的程序員即使從來沒有讀過設(shè)計(jì)模式、從來沒有聽說過單一職責(zé)原則,在設(shè)計(jì)軟件時(shí)也會自覺的遵守這一重要原則,因?yàn)檫@是常識。在軟件編程中,誰也不希望因?yàn)樾薷牧艘粋€(gè)功能導(dǎo)致其他的功能發(fā)生故障。而避免出現(xiàn)這一問題的方法便是遵循單一職責(zé)原則。雖然單一職責(zé)原則如此簡單,并且被認(rèn)為是常識,但是即便是經(jīng)驗(yàn)豐富的程序員寫出的程序,也會有違背這一原則的代碼存在。為什么會出現(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é)原則的。后來由于某種原因,也許是需求變更了,也許是程序的設(shè)計(jì)者境界提高了,需要將職責(zé)P細(xì)分為粒度更細(xì)的職責(zé)P1,P2,這時(shí)如果要使程序遵循單一職責(zé)原則,需要將類T也分解為兩個(gè)類T1和T2,分別負(fù)責(zé)P1、P2兩個(gè)職責(zé)。但是在程序已經(jīng)寫好的情況下,這樣做簡直太費(fèi)時(shí)間了。所以,簡單的修改類T,用它來負(fù)責(zé)兩個(gè)職責(zé)是一個(gè)比較不錯(cuò)的選擇,雖然這樣做有悖于單一職責(zé)原則。(這樣做的風(fēng)險(xiǎn)在于職責(zé)擴(kuò)散的不確定性,因?yàn)槲覀儾粫氲竭@個(gè)職責(zé)P,在未來可能會擴(kuò)散為P1,P2,P3,P4……Pn。所以記住,在職責(zé)擴(kuò)散到我們無法控制的程度之前,立刻對代碼進(jìn)行重構(gòu)。)
舉例說明,用一個(gè)類描述動物呼吸這個(gè)場景:
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)問題了,并不是所有的動物都呼吸空氣的,比如魚就是呼吸水的。修改時(shí)如果遵循單一職責(zé)原則,需要將Animal類細(xì)分為陸生動物類Terrestrial,水生動物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ùn)行結(jié)果:
牛呼吸空氣
羊呼吸空氣
豬呼吸空氣
魚呼吸水
我們會發(fā)現(xiàn)如果這樣修改花銷是很大的,除了將原來的類分解之外,還需要修改客戶端。而直接修改類Animal來達(dá)成目的雖然違背了單一職責(zé)原則,但花銷卻小的多,代碼如下:
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方法,而對原有代碼的修改會對調(diào)用“豬”“?!薄把颉钡认嚓P(guān)功能帶來風(fēng)險(xiǎn),也許某一天你會發(fā)現(xiàn)程序運(yùn)行的結(jié)果變?yōu)椤芭:粑绷?。這種修改方式直接在代碼級別上違背了單一職責(zé)原則,雖然修改起來最簡單,但隱患卻是大的。還有一種修改方式:
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("魚"); } }
可以看到,這種修改方式?jīng)]有改動原來的方法,而是在類中新加了一個(gè)方法,這樣雖然也違背了單一職責(zé)原則,但在方法級別上卻是符合單一職責(zé)原則的,因?yàn)樗]有動原來方法的代碼。這三種方式各有優(yōu)缺點(diǎn),那么在實(shí)際編程中,采用哪一中呢?其實(shí)這真的比較難說,需要根據(jù)實(shí)際情況來確定。我的原則是:只有邏輯足夠簡單,才可以在代碼級別上違反單一職責(zé)原則;只有類中方法數(shù)量足夠少,才可以在方法級別上違反單一職責(zé)原則;
例如本文所舉的這個(gè)例子,它太簡單了,它只有一個(gè)方法,所以,無論是在代碼級別上違反單一職責(zé)原則,還是在方法級別上違反,都不會造成太大的影響。實(shí)際應(yīng)用中的類都要復(fù)雜的多,一旦發(fā)生職責(zé)擴(kuò)散而需要修改類時(shí),除非這個(gè)類本身非常簡單,否則還是遵循單一職責(zé)原則的好。
遵循單一職責(zé)原的優(yōu)點(diǎn)有:
?可以降低類的復(fù)雜度,一個(gè)類只負(fù)責(zé)一項(xiàng)職責(zé),其邏輯肯定要比負(fù)責(zé)多項(xiàng)職責(zé)簡單的多;
?提高類的可讀性,提高系統(tǒng)的可維護(hù)性;
?變更引起的風(fēng)險(xiǎn)降低,變更是必然的,如果單一職責(zé)原則遵守的好,當(dāng)修改一個(gè)功能時(shí),可以顯著降低對其他功能的影響。
需要說明的一點(diǎn)是單一職責(zé)原則不只是面向?qū)ο缶幊趟枷胨赜械?,只要是模塊化的程序設(shè)計(jì),都適用單一職責(zé)原則。
上述就是小編為大家分享的什么實(shí)現(xiàn)Java項(xiàng)目中的單一職責(zé)原則了,如果剛好有類似的疑惑,不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識,歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。