敏捷軟件開發

單一職責原則(SRP)

介紹

就一個類而言,應該僅有一個引起它變化的原因。

實現方法之一就是把不同職責分離到不同的類中。因為每一個職責都是變化的一個軸線。當需求變化時,該變化會反映為類的職責的變化。如果一個類承擔了多于一個的職責,那么引起它變化的原因就會有多個。

如果一個類承擔的職責過多,就等于把這些職責耦合在了一起。一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計,當變化發生時,設計會遭受到意想不到的破壞。

職責

關于職責,可以定位為“變化的原因”。如果你能夠想到多于一個的動機去改變一個類,那么這個類就具有多于一個的職責。但我們習慣以組的形式去考慮職責。例如下面的Modem接口,大多數人會認為這個接口看起來非常合理:

interface Modem
{
    public void dial(String pno);
    public void hangup();
    public void send(char c);
    public void recv();
}

然而,該接口中卻顯示了兩個職責。第一個職責是連接管理;第二個職責是數據通信。dial和hangup函數進行調制解調器的連接處理,而send和recv函數進行數據通信。

這兩個職責應該被分開嗎?這依賴于應用程序變化的方式。如果應用程序的變化會影響連接函數的簽名,那么這個設計就具有僵化性的臭味,因為調用send和recv的類必須要重新編譯,部署的次數常常會超過我們希望的次數。這種情況下,這兩個職責應該被分離,這樣做避免了客戶應用程序和這兩職責耦合在一起。

另一方面,如果應用程序的變化方式總是導致這兩個職責同時變化,那么就不必分離它們。實際上,分離它們就會具有不必要的復雜性的臭味。

在此還有一個推論。變化的軸線僅當變化實際發生時才具有真正的意義。如果沒有征兆,那么去應用SRP,或者任何其他原則都是不明智的。

開放——封閉原則(OCP)

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容