淺談c#設(shè)計(jì)模式之單一原則
單一原則: 程序設(shè)計(jì)時(shí)功能模塊獨(dú)立,功能單一更有助于維護(hù)和復(fù)用。
例如:個(gè)人計(jì)算機(jī)功能很多,如果想從中只拿出一個(gè)功能來制造一個(gè)新的東西是困難的。同時(shí)如果你的計(jì)算機(jī)開不機(jī),同時(shí)你的計(jì)算器功能也不能用了。
在編程中如果一個(gè)類封裝了太多功能和上面的結(jié)果是類似的。
單一職責(zé)原則
例1:
大家應(yīng)該能看出來這個(gè)類圖中的接口設(shè)計(jì)是有問題的,用戶的屬性和用戶的行為沒有分開。我們根據(jù)用戶的屬性和行為拆開這個(gè)接口。
重新拆分成兩個(gè)接口,IUserBo 負(fù)責(zé)用戶的屬性,IUserBiz負(fù)責(zé)用戶的行為。當(dāng)我們實(shí)例化除UserINfo這個(gè)對象后,我們可以把UserInfo當(dāng)做IUserBo實(shí)現(xiàn)類使用也可以將它當(dāng)做IUserBiz的實(shí)現(xiàn)類使用,這就要看我們用在什么地方了。如果是獲取用戶信息,就把UserInfo 當(dāng)做IUserBOSS的實(shí)現(xiàn)類,如果是維護(hù)用戶信息,就當(dāng)做是IUserBiz的實(shí)現(xiàn)類。在實(shí)際應(yīng)用中我們更傾向于把一個(gè)接口拆分成兩個(gè),一個(gè)是IUserBO一個(gè)是IUserBIz。類圖如下。
這樣做以后,我們就把一個(gè)接口拆成了兩個(gè),這樣就符合了單一職責(zé)原則,那么什么是單一職責(zé)原則呢?
單一職責(zé)原則,核心思想是:一個(gè)類,最好只做一件事,只有一個(gè)引起它變化的原因。
單一職責(zé)原則可以看作是低耦合、高內(nèi)聚在面向?qū)ο笤瓌t上的引申,將職責(zé)定義為引起變化的原因,以提高內(nèi)聚性來減少引起變化的原因。職責(zé)過多,可能引起變化的原因就越多,這將是導(dǎo)致職責(zé)依賴,相互之間就產(chǎn)生影響,從而極大的損傷其內(nèi)聚性和耦合度。單一職責(zé)通常意味著單一的功能,因此不要為類實(shí)現(xiàn)過多的功能點(diǎn),以保證實(shí)體只有一個(gè)引起它變化的原因。例2:
Rectangle擁有兩個(gè)方法,一個(gè)方法是draw,用來畫圖形,另一個(gè)方法是area用來計(jì)算面積。Rectangle違背了單一職責(zé)原則,因?yàn)樗哂袃蓚€(gè)職責(zé):計(jì)算面積與繪制矩形。繪制圖形會與用戶界面有關(guān),但是計(jì)算圖形面積卻未必與界面有關(guān),如果把這兩個(gè)職責(zé)寫到一個(gè)類中,那么如果只需要使用area()方法這一職責(zé)來計(jì)算面積,那就不得不把draw()方法一同編譯,但是卻可能也用不到它。如果其中一個(gè)職責(zé)需要修改,就不得不重新編譯和部署另外一個(gè)。如果類的職責(zé)超過一個(gè),這些職責(zé)之間就會產(chǎn)生耦合。改變一個(gè)職責(zé),可能會影響和妨礙類為其它類服務(wù)的功能。把兩個(gè)職責(zé)分開會好一些。
兩個(gè)職責(zé)分離,這樣耦合度就會降低。SRP原則的核心就是要求對類的改變只能是一個(gè),對于違反這一原則的類應(yīng)該進(jìn)行重構(gòu),例如以Façade模式或Proxy模式分離職責(zé),通過基本的方法Extract Interface、Extract Class和Extract Method進(jìn)行梳理。
例3:看一下下面的接口
public interface Phone
{
//撥通電話
public void dial(string phoneNumber);
//通話
public void chat(object o);
//回應(yīng)
public void answer(object o);
//通話完畢
public void huangup();
}
這個(gè)接口有問題嗎?還真有問題。單一職責(zé)要求一個(gè)接口或者類只有一個(gè)原因引起變化,也就是一個(gè)接口或者類只有一個(gè)職責(zé),它負(fù)責(zé)一件事情。Phone這個(gè)接口不是一個(gè)職責(zé),它是有兩個(gè)職責(zé):一個(gè)是協(xié)議管理,一個(gè)是數(shù)據(jù)傳輸。diag()和huangup()這兩個(gè)方法實(shí)現(xiàn)的是協(xié)議管理,撥號和掛斷。chat()和answer()是數(shù)據(jù)傳輸。協(xié)議改變和數(shù)據(jù)傳輸都會引起類的變化,那么我們就不能說它是符合單一職責(zé)原則。由于這兩個(gè)職責(zé)變化不互相影響,那么就考慮拆成兩個(gè)接口。
這個(gè)類圖已經(jīng)符合單一職責(zé)原則,但是卻復(fù)雜多了,組合是一種強(qiáng)耦合關(guān)系,兩者都有共同的生命期,這種強(qiáng)耦合增加了類的復(fù)雜性,我們修改一下。
這樣設(shè)計(jì)才完美,一個(gè)手機(jī)實(shí)現(xiàn)兩個(gè)接口,把兩個(gè)職責(zé)融合一個(gè)類中,雖然你會覺得這個(gè)phone類有兩個(gè)原因引起變化,但是我們是面向接口編程,對外公布的是接口,而不是實(shí)現(xiàn)類。如果非要使得類符合單一職責(zé)原則,那么就要使用上一個(gè)類圖了,但是這樣的話類的耦合性就增加了.
單一職責(zé)原則的好處:類的復(fù)雜性降低可讀性提高可維護(hù)性提高變更引起的風(fēng)險(xiǎn)降低
相關(guān)文章
ASP.NET Core 過濾器中使用依賴注入知識點(diǎn)總結(jié)
在本篇文章里小編給大家分享的是關(guān)于ASP.NET Core 過濾器中使用依賴注入的相關(guān)知識點(diǎn)內(nèi)容,需要的朋友們學(xué)習(xí)下。2019-10-10基于.Net?Core認(rèn)證授權(quán)方案之JwtBearer認(rèn)證
這篇文章介紹了基于.Net?Core認(rèn)證授權(quán)方案之JwtBearer認(rèn)證,文中通過示例代碼介紹的非常詳細(xì)。對大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2022-06-06asp.net 動態(tài)創(chuàng)建TextBox控件及狀態(tài)數(shù)據(jù)如何加載
接著上文Asp.net TextBox的TextChanged事件你真的清楚嗎?這里我們來說說狀態(tài)數(shù)據(jù)時(shí)如何加載的,需要的朋友可以參考下2012-12-12ASP.NET顯示農(nóng)歷時(shí)間改進(jìn)版
這篇文章主要介紹了ASP.NET顯示農(nóng)歷時(shí)間改進(jìn)版,是針對前面一篇ASP.NET顯示農(nóng)歷時(shí)間的改進(jìn)版,實(shí)現(xiàn)了比較簡單的封裝,增加了易用性,非常具有實(shí)用價(jià)值,需要的朋友可以參考下2014-11-11ASP.NET數(shù)據(jù)綁定之DataList控件
這篇文章主要為大家介紹了ASP.NET數(shù)據(jù)綁定中的DataList控件,DataList控件以表的形式呈現(xiàn)數(shù)據(jù),通過該控件,您可以使用不同的布局來顯示數(shù)據(jù)記錄,對DataList控件感興趣的小伙伴們可以參考一下2016-01-01Repeater控件動態(tài)變更列(Header,Item和Foot)信息(重構(gòu)cs)
上一篇雖然它算不上是完全動態(tài)化,但它已經(jīng)達(dá)到初期想要的效果,現(xiàn)另開一篇,不是重新另外寫,而是想重構(gòu)cs的代碼,因?yàn)榍耙黄拇a雖然簡單,但代碼冗余過多,感興趣的朋友可以參考下哈2013-03-03