php的設計原則:單一職責原則

單一職責原則(SRP:Single responsibility principle)又稱單一功能原則

定義:不要存在多於一個導致類變更的原因。通俗的說,即一個類只負責一項職責。 
問題由來:類T負責兩個不同的職責:職責P1,職責P2。當由於職責P1需求發生改變而需要修改類T時,有可能會導致原本運行正常的職責P2功能發生故障。

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

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

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

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

 

class Animal{
    public function breathe($animal)
    {
        echo $animal . "呼吸空氣\n";
    }
}

$animal = new Animal();
$animal->breathe("牛");  //牛呼吸空氣
$animal->breathe("羊");  //羊呼吸空氣
$animal->breathe("豬");  //豬呼吸空氣

 

程序上線後,發現問題了,並不是所有的動物都呼吸空氣的,比如魚就是呼吸水的。修改時如果遵循單一職責原則,需要將Animal類細分爲陸生動物類Terrestrial,水生動物Aquatic,代碼如下:

 

class Terrestrial{
    public function breathe(String $animal)
    {
        echo $animal . "呼吸空氣\n";
    }
}

class Aquatic{
    public function breathe(String $animal)
    {
        echo $animal . "呼吸水\n";
    }
}

$terrestrial = new Terrestrial();
$terrestrial->breathe("牛");
$terrestrial->breathe("羊");
$terrestrial->breathe("豬");

$aquatic = new Aquatic();
$aquatic->breathe("魚");  //魚呼吸水

 

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

 

class Terrestrial{
    public function breathe(String $animal)
    {
        if ($animal == '魚'){
            echo $animal . "呼吸水\n";
        } else {
            echo $animal . "呼吸空氣\n";
        }

    }
}

$terrestrial = new Terrestrial();
$terrestrial->breathe("牛");
$terrestrial->breathe("羊");
$terrestrial->breathe("豬");
$terrestrial->breathe("魚");  //魚呼吸水

 

可以看到,這種修改方式要簡單的多。但是卻存在着隱患:有一天需要將魚分爲呼吸淡水的魚和呼吸海水的魚,則又需要修改Animal類的breathe方法,而對原有代碼的修改會對調用“豬”“牛”“羊”等相關功能帶來風險,也許某一天你會發現程序運行的結果變爲“牛呼吸水”了。這種修改方式直接在代碼級別上違背了單一職責原則,雖然修改起來最簡單,但隱患卻是最大的。還有一種修改方式:

 

class Terrestrial{
    public function breathe(String $animal)
    {
        echo $animal . "呼吸空氣\n";
    }
    public function breathe2(String $animal)
    {
        echo $animal . "呼吸水\n";
    }
}

$terrestrial = new Terrestrial();
$terrestrial->breathe("牛");
$terrestrial->breathe("羊");
$terrestrial->breathe("豬");
$terrestrial->breathe2("魚");  //魚呼吸水

 

可以看到,這種修改方式沒有改動原來的方法,而是在類中新加了一個方法,這樣雖然也違背了單一職責原則,但在方法級別上卻是符合單一職責原則的,因爲它並沒有動原來方法的代碼。這三種方式各有優缺點,那麼在實際編程中,採用哪一中呢?其實這真的比較難說,需要根據實際情況來確定。我的原則是:只有邏輯足夠簡單,纔可以在代碼級別上違反單一職責原則;只有類中方法數量足夠少,纔可以在方法級別上違反單一職責原則;

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

遵循單一職責原的優點有:

  • 可以降低類的複雜度,一個類只負責一項職責,其邏輯肯定要比負責多項職責簡單的多;
  • 提高類的可讀性,提高系統的可維護性;
  • 變更引起的風險降低,變更是必然的,如果單一職責原則遵守的好,當修改一個功能時,可以顯著降低對其他功能的影響。

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

優缺點:

優點:

  • 功能單一,職責清晰。
  • 可讀性強,方便維護。

缺點:

  • 拆分的太詳細,類的數量會急劇增加。
  • 職責的度量沒有同意的標準,需要根據實際情況而定。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章