單一職責定義：

不要存在多於一個導致類變更的原因，通俗的說，即一個類只負責一項職責。

問題由來：

類T負責兩個不同的職責：職責P1，職責P2。當由於職責P1需求發生改變而需要修改類T時，有可能會導致原本運行正常的職責P2功能發生故障。

解決方案：

遵循單一職責原則。分別建立兩個類T1、T2，使T1完成職責P1功能，T2完成職責P2功能。這樣，當修改類T1時，不會使職責P2發生故障風險；同理，當修改T2時，也不會使職責P1發生故障風險。

ps:

說到單一職責原則，很多人都會不屑一顧。因為它太簡單了。稍有經驗的程序員即使從來沒有讀過設計模式、從來沒有聽說過單一職責原則，在設計軟件時也會自覺的遵守這一重要原則，因為這是常識。在軟件編程中，誰也不希望因為修改了一個功能導致其他的功能發生故障。而避免出現這一問題的方法便是遵循單一職責原則。雖然單一職責原則如此簡單，並且被認為是常識，但是即便是經驗豐富的程序員寫出的程序，也會有違背這一原則的代碼存在。為什麽會出現這種現象呢？因為有職責擴散。所謂職責擴散，就是因為某種原因，職責P被分化為粒度更細的職責P1和P2。

比如：類T只負責一個職責P，這樣設計是符合單一職責原則的。後來由於某種原因，也許是需求變更了，也許是程序的設計者境界提高了，需要將職責P細分為粒度更細的職責P1，P2，這時如果要使程序遵循單一職責原則，需要將類T也分解為兩個類T1和T2，分別負責P1、P2兩個職責。但是在程序已經寫好的情況下，這樣做簡直太費時間了。所以，簡單的修改類T，用它來負責兩個職責是一個比較不錯的選擇，雖然這樣做有悖於單一職責原則。（這樣做的風險在於職責擴散的不確定性，因為我們不會想到這個職責P，在未來可能會擴散為P1，P2，P3，P4……Pn。所以記住，在職責擴散到我們無法控制的程度之前，立刻對代碼進行重構。）

C#代碼舉例說明：

我們用一個天空類, 去描述一個動物飛的動作。

 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 + "天上飛");
        }
    }

但是仔細看, 會發現問題, 並不是所有的動物都會在天上飛, 比如狗, 它就是在地上跑。

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

class Program
    {
        static void Main(string[] args)
        {
            Sky SkyExample = new Sky();
            SkyExample.fly("飛機");
            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 + "地上跑");
        }
    }

可以看到，這種修改方式沒有改動原來的類，而是新增了一個類加了一個方法, 這個即在類級別符合單一職責原則, 也在方法上符合單一職責, 因為它沒有動或影響原來的代碼, 但是在實際的

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

顯然, 這種方法違背了單一職責原則, 但是這樣在方法級別上是符合單一職責原則得。

遵循單一職責原的優點：

· 可以降低類的復雜度，一個類只負責一項職責，其邏輯肯定要比負責多項職責簡單的多；

· 提高類的可讀性，提高系統的可維護性；

· 變更引起的風險降低，變更是必然的，如果單一職責原則遵守的好，當修改一個功能時，可以顯著降低對其他功能的影響。

ps: 需要說明的一點是單一職責原則不只是面向對象編程思想所特有的，只要是模塊化的程序設計，都適用單一職責原則。

設計模式六大原則(一)：單一職責原則