c#設(shè)計模式中的單一職責(zé)原則

本篇內(nèi)容介紹了“c#設(shè)計模式中的單一職責(zé)原則”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

單一原則： 程序設(shè)計時功能模塊獨立，功能單一更有助于維護和復(fù)用。

例如：個人計算機功能很多，如果想從中只拿出一個功能來制造一個新的東西是困難的。同時如果你的計算機開不機，同時你的計算器功能也不能用了。

在編程中如果一個類封裝了太多功能和上面的結(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)類，如果是維護用戶信息，就當(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)該進行重構(gòu)，例如以Façade模式或Proxy模式分離職責(zé)，通過基本的方法Extract Interface、Extract Class和Extract Method進行梳理。

例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ù)雜多了，組合是一種強耦合關(guān)系，兩者都有共同的生命期，這種強耦合增加了類的復(fù)雜性，我們修改一下。

這樣設(shè)計才完美，一個手機實現(xiàn)兩個接口，把兩個職責(zé)融合一個類中，雖然你會覺得這個phone類有兩個原因引起變化，但是我們是面向接口編程，對外公布的是接口，而不是實現(xiàn)類。如果非要使得類符合單一職責(zé)原則，那么就要使用上一個類圖了，但是這樣的話類的耦合性就增加了.

單一職責(zé)原則的好處：類的復(fù)雜性降低可讀性提高可維護性提高變更引起的風(fēng)險降低

“c#設(shè)計模式中的單一職責(zé)原則”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！