單一職責(zé)(SRP)定義：

不要存在多于一個(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í)，有可能會(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)。

ps:

說到單一職責(zé)原則，很多人都會(huì)不屑一顧。因?yàn)樗?jiǎn)單了。稍有經(jīng)驗(yàn)的程序員即使從來沒有讀過設(shè)計(jì)模式、從來沒有聽說過單一職責(zé)原則，在設(shè)計(jì)軟件時(shí)也會(huì)自覺的遵守這一重要原則，因?yàn)檫@是常識(shí)。在軟件編程中，誰也不希望因?yàn)樾薷牧艘粋€(gè)功能導(dǎo)致其他的功能發(fā)生故障。而避免出現(xiàn)這一問題的方法便是遵循單一職責(zé)原則。雖然單一職責(zé)原則如此簡(jiǎn)單，并且被認(rèn)為是常識(shí)，但是即便是經(jīng)驗(yàn)豐富的程序員寫出的程序，也會(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é)原則的。后來由于某種原因，也許是需求變更了，也許是程序的設(shè)計(jì)者境界提高了，需要將職責(zé)P細(xì)分為粒度更細(xì)的職責(zé)P1，P2，這時(shí)如果要使程序遵循單一職責(zé)原則，需要將類T也分解為兩個(gè)類T1和T2，分別負(fù)責(zé)P1、P2兩個(gè)職責(zé)。但是在程序已經(jīng)寫好的情況下，這樣做簡(jiǎn)直太費(fèi)時(shí)間了。所以，簡(jiǎn)單的修改類T，用它來負(fù)責(zé)兩個(gè)職責(zé)是一個(gè)比較不錯(cuò)的選擇，雖然這樣做有悖于單一職責(zé)原則。（這樣做的風(fēng)險(xiǎn)在于職責(zé)擴(kuò)散的不確定性，因?yàn)槲覀儾粫?huì)想到這個(gè)職責(zé)P，在未來可能會(huì)擴(kuò)散為P1，P2，P3，P4……Pn。所以記住，在職責(zé)擴(kuò)散到我們無法控制的程度之前，立刻對(duì)代碼進(jìn)行重構(gòu)。）

C#代碼舉例說明：

我們用一個(gè)天空類, 去描述一個(gè)動(dòng)物飛的動(dòng)作。

class Program
    {
        static void Main(string[] args)
        {
            Sky SkyExample = new Sky();
            SkyExample.fly("老鷹");
            SkyExample.fly("麻雀");
            
            Console.ReadKey();
        }
    }

    public class Sky
    {
        public void fly(string name)
        {
            Console.WriteLine(name + "天上飛");
        }
    }

但是仔細(xì)看, 會(huì)發(fā)現(xiàn)問題, 并不是所有的動(dòng)物都會(huì)在天上飛, 比如狗, 它就是在地上跑。

所以要去修改它, 但如果要在遵循單一職責(zé)的原則下, 我們則需要新增一個(gè)地的類(Land), 提供一部分跑的動(dòng)作 (run),

class Program
    {
        static void Main(string[] args)
        {
            Sky SkyExample = new Sky();
            SkyExample.fly("飛機(jī)");
            SkyExample.fly("老鷹");
            SkyExample.fly("麻雀");

            Land LandExample = new Land();
            LandExample.run("豬");
            LandExample.run("狗");
            LandExample.run("馬");

            Console.ReadKey();
        }
    }

    public class Sky
    {
        public void fly(string name)
        {
            Console.WriteLine(name + "天上飛");
        }
    }

    public class Land
    {
        public void run(string name)
        {
            Console.WriteLine(name + "地上跑");
        }
    }

可以看到，這種修改方式?jīng)]有改動(dòng)原來的類，而是新增了一個(gè)類加了一個(gè)方法, 這個(gè)即在類級(jí)別符合單一職責(zé)原則, 也在方法上符合單一職責(zé), 因?yàn)樗鼪]有動(dòng)或影響原來的代碼, 但是在實(shí)際的

開發(fā)過程中, 我們往往會(huì)將類變得更抽象(sky則改成不再是天空,變成Animal), 而我們則需要在 Animal 類下, 提供多個(gè)方法, 可以 fly,run,climb等等, 這樣也就不會(huì)我們重新建一個(gè)類去到達(dá)目的。

顯然, 這種方法違背了單一職責(zé)原則, 但是這樣在方法級(jí)別上是符合單一職責(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ì)其他功能的影響。

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

到此這篇關(guān)于C#實(shí)現(xiàn)六大設(shè)計(jì)原則之單一職責(zé)原則的文章就介紹到這了。希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評(píng)論