單一職責原則（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，或者任何其他原則都是不明智的。
