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

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

舉例說明，用一個類描述動物呼吸這個場景：

    class Animal{
        public void breathe(String animal){
            System.out.println(animal+"呼吸空氣");
        }
    }
    public class Client{
        public static void main(String[] args){
            Animal animal = new Animal();
            animal.breathe("牛");
            animal.breathe("羊");
            animal.breathe("豬");
        }
    }

運行結(jié)果：

牛呼吸空氣  
羊呼吸空氣  
豬呼吸空氣

程序上線后，發(fā)現(xiàn)問題了，并不是所有的動物都呼吸空氣的，比如魚就是呼吸水的。修改時如果遵循單一職責(zé)原則，需要將Animal類細分為陸生動物類Terrestrial，水生動物Aquatic，代碼如下：

    class Terrestrial{
        public void breathe(String animal){
            System.out.println(animal+"呼吸空氣");
        }
    }
    class Aquatic{
        public void breathe(String animal){
            System.out.println(animal+"呼吸水");
        }
    }

    public class Client{
        public static void main(String[] args){
            Terrestrial terrestrial = new Terrestrial();
            terrestrial.breathe("牛");
            terrestrial.breathe("羊");
            terrestrial.breathe("豬");

            Aquatic aquatic = new Aquatic();
            aquatic.breathe("魚");
        }
    }

運行結(jié)果：

牛呼吸空氣  
羊呼吸空氣  
豬呼吸空氣  
魚呼吸水

我們會發(fā)現(xiàn)如果這樣修改花銷是很大的，除了將原來的類分解之外，還需要修改客戶端。而直接修改類Animal來達成目的雖然違背了單一職責(zé)原則，但花銷卻小的多，代碼如下：

    class Animal{
        public void breathe(String animal){
            if("魚".equals(animal)){
                System.out.println(animal+"呼吸水");
            }else{
                System.out.println(animal+"呼吸空氣");
            }
        }
    }

    public class Client{
        public static void main(String[] args){
            Animal animal = new Animal();
            animal.breathe("牛");
            animal.breathe("羊");
            animal.breathe("豬");
            animal.breathe("魚");
        }
    }

可以看到，這種修改方式要簡單的多。但是卻存在著隱患：有一天需要將魚分為呼吸淡水的魚和呼吸海水的魚，則又需要修改Animal類的breathe方法，而對原有代碼的修改會對調(diào)用"豬""牛""羊"等相關(guān)功能帶來風(fēng)險，也許某一天你會發(fā)現(xiàn)程序運行的結(jié)果變?yōu)?quot;牛呼吸水"了。這種修改方式直接在代碼級別上違背了單一職責(zé)原則，雖然修改起來最簡單，但隱患卻是最大的。還有一種修改方式：

    class Animal{
        public void breathe(String animal){
            System.out.println(animal+"呼吸空氣");
        }

        public void breathe2(String animal){
            System.out.println(animal+"呼吸水");
        }
    }

    public class Client{
        public static void main(String[] args){
            Animal animal = new Animal();
            animal.breathe("牛");
            animal.breathe("羊");
            animal.breathe("豬");
            animal.breathe2("魚");
        }
    }

可以看到，這種修改方式?jīng)]有改動原來的方法，而是在類中新加了一個方法，這樣雖然也違背了單一職責(zé)原則，但在方法級別上卻是符合單一職責(zé)原則的，因為它并沒有動原來方法的代碼。這三種方式各有優(yōu)缺點，那么在實際編程中，采用哪一中呢？其實這真的比較難說，需要根據(jù)實際情況來確定。我的原則是：只有邏輯足夠簡單，才可以在代碼級別上違反單一職責(zé)原則；只有類中方法數(shù)量足夠少，才可以在方法級別上違反單一職責(zé)原則；

例如本文所舉的這個例子，它太簡單了，它只有一個方法，所以，無論是在代碼級別上違反單一職責(zé)原則，還是在方法級別上違反，都不會造成太大的影響。實際應(yīng)用中的類都要復(fù)雜的多，一旦發(fā)生職責(zé)擴散而需要修改類時，除非這個類本身非常簡單，否則還是遵循單一職責(zé)原則的好。

遵循單一職責(zé)原的優(yōu)點有：

可以降低類的復(fù)雜度，一個類只負責(zé)一項職責(zé)，其邏輯肯定要比負責(zé)多項職責(zé)簡單的多；
提高類的可讀性，提高系統(tǒng)的可維護性；
變更引起的風(fēng)險降低，變更是必然的，如果單一職責(zé)原則遵守的好，當(dāng)修改一個功能時，可以顯著降低對其他功能的影響。

需要說明的一點是單一職責(zé)原則不只是面向?qū)ο缶幊趟枷胨赜械模灰悄K化的程序設(shè)計，都適用單一職責(zé)原則。

下一篇：開閉原則