淺談c#設(shè)計模式之單一原則
單一原則: 程序設(shè)計時功能模塊獨立,功能單一更有助于維護(hù)和復(fù)用。
例如:個人計算機(jī)功能很多,如果想從中只拿出一個功能來制造一個新的東西是困難的。同時如果你的計算機(jī)開不機(jī),同時你的計算器功能也不能用了。
在編程中如果一個類封裝了太多功能和上面的結(jié)果是類似的。
單一職責(zé)原則
例1:

大家應(yīng)該能看出來這個類圖中的接口設(shè)計是有問題的,用戶的屬性和用戶的行為沒有分開。我們根據(jù)用戶的屬性和行為拆開這個接口。

重新拆分成兩個接口,IUserBo 負(fù)責(zé)用戶的屬性,IUserBiz負(fù)責(zé)用戶的行為。當(dāng)我們實例化除UserINfo這個對象后,我們可以把UserInfo當(dāng)做IUserBo實現(xiàn)類使用也可以將它當(dāng)做IUserBiz的實現(xiàn)類使用,這就要看我們用在什么地方了。如果是獲取用戶信息,就把UserInfo 當(dāng)做IUserBOSS的實現(xiàn)類,如果是維護(hù)用戶信息,就當(dāng)做是IUserBiz的實現(xiàn)類。在實際應(yīng)用中我們更傾向于把一個接口拆分成兩個,一個是IUserBO一個是IUserBIz。類圖如下。

這樣做以后,我們就把一個接口拆成了兩個,這樣就符合了單一職責(zé)原則,那么什么是單一職責(zé)原則呢?
單一職責(zé)原則,核心思想是:一個類,最好只做一件事,只有一個引起它變化的原因。
單一職責(zé)原則可以看作是低耦合、高內(nèi)聚在面向?qū)ο笤瓌t上的引申,將職責(zé)定義為引起變化的原因,以提高內(nèi)聚性來減少引起變化的原因。職責(zé)過多,可能引起變化的原因就越多,這將是導(dǎo)致職責(zé)依賴,相互之間就產(chǎn)生影響,從而極大的損傷其內(nèi)聚性和耦合度。單一職責(zé)通常意味著單一的功能,因此不要為類實現(xiàn)過多的功能點,以保證實體只有一個引起它變化的原因。例2:
Rectangle擁有兩個方法,一個方法是draw,用來畫圖形,另一個方法是area用來計算面積。Rectangle違背了單一職責(zé)原則,因為它具有兩個職責(zé):計算面積與繪制矩形。繪制圖形會與用戶界面有關(guān),但是計算圖形面積卻未必與界面有關(guān),如果把這兩個職責(zé)寫到一個類中,那么如果只需要使用area()方法這一職責(zé)來計算面積,那就不得不把draw()方法一同編譯,但是卻可能也用不到它。如果其中一個職責(zé)需要修改,就不得不重新編譯和部署另外一個。如果類的職責(zé)超過一個,這些職責(zé)之間就會產(chǎn)生耦合。改變一個職責(zé),可能會影響和妨礙類為其它類服務(wù)的功能。把兩個職責(zé)分開會好一些。

兩個職責(zé)分離,這樣耦合度就會降低。SRP原則的核心就是要求對類的改變只能是一個,對于違反這一原則的類應(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();
}
這個接口有問題嗎?還真有問題。單一職責(zé)要求一個接口或者類只有一個原因引起變化,也就是一個接口或者類只有一個職責(zé),它負(fù)責(zé)一件事情。Phone這個接口不是一個職責(zé),它是有兩個職責(zé):一個是協(xié)議管理,一個是數(shù)據(jù)傳輸。diag()和huangup()這兩個方法實現(xiàn)的是協(xié)議管理,撥號和掛斷。chat()和answer()是數(shù)據(jù)傳輸。協(xié)議改變和數(shù)據(jù)傳輸都會引起類的變化,那么我們就不能說它是符合單一職責(zé)原則。由于這兩個職責(zé)變化不互相影響,那么就考慮拆成兩個接口。
這個類圖已經(jīng)符合單一職責(zé)原則,但是卻復(fù)雜多了,組合是一種強(qiáng)耦合關(guān)系,兩者都有共同的生命期,這種強(qiáng)耦合增加了類的復(fù)雜性,我們修改一下。

這樣設(shè)計才完美,一個手機(jī)實現(xiàn)兩個接口,把兩個職責(zé)融合一個類中,雖然你會覺得這個phone類有兩個原因引起變化,但是我們是面向接口編程,對外公布的是接口,而不是實現(xiàn)類。如果非要使得類符合單一職責(zé)原則,那么就要使用上一個類圖了,但是這樣的話類的耦合性就增加了.
單一職責(zé)原則的好處:類的復(fù)雜性降低可讀性提高可維護(hù)性提高變更引起的風(fēng)險降低
相關(guān)文章
asp.net Page.Controls對象(找到所有服務(wù)器控件)
通過此對象找到所有服務(wù)器控件。2008-11-11
asp.net動態(tài)獲取Excel表名的函數(shù)代碼
asp.net動態(tài)獲取Excel表名的函數(shù)代碼,需要的朋友可以參考下。2011-02-02
ASP.NET中使用GridView實現(xiàn)分級顯示的代碼
在實際項目開發(fā)中,往往需要用到在頁面上對列表的項目實現(xiàn)分級顯示,在 ASP.NET中沒有現(xiàn)成的控件。2010-06-06
ASP.NET MVC5網(wǎng)站開發(fā)用戶修改資料和密碼(六)
這篇文章主要介紹了ASP.NET MVC5網(wǎng)站開發(fā)用戶修改資料和密碼,本文即將結(jié)束member區(qū)域的用戶部分,感興趣的小伙伴們可以參考一下2015-09-09
ASP.NET My97DatePicker日期控件實現(xiàn)OA日期記事功能
這篇文章主要介紹了ASP.NET My97DatePicker日期控件實現(xiàn)OA日期記事功能的相關(guān)資料,需要的朋友可以參考下2016-04-04
淺析Repeater控件的使用 (原樣導(dǎo)出和動態(tài)顯示/隱藏Repeater中的列)
本文主要介紹了淺析Repeater控件的使用 (原樣導(dǎo)出和動態(tài)顯示/隱藏Repeater中的列)的具體方法,需要的朋友可以看下2016-12-12
ASP.net與SQLite數(shù)據(jù)庫通過js和ashx交互(連接和操作)
這篇文章主要介紹了ASP.net與SQLite數(shù)據(jù)庫通過js和ashx交互(連接和操作),具有一定的參考價值,有興趣的可以了解一下。2017-01-01
ASP.NET 生成靜態(tài)頁面 實現(xiàn)思路
網(wǎng)上的cms系統(tǒng)好多都是支持生成靜態(tài)的,大家在使用過程中,也肯定遇到了很多的問題,下面就是一些實現(xiàn)的原理,其實 asp,php,asp.net的原理都是差不多的。2009-06-06

