靈活軟體開發——單一職責原則

      在說【單一職責原則】之前，先說一下什麼是内聚性。

      内聚性：是一個子產品内的組成元素之間的功能相關性。在本文中，将這個概念延伸一下，把内聚性和引起一個子產品或者類改變的作用力聯系起來。

      現在，就介紹一下什麼是【單一職責原則】。

      單一職責原則：就一個類而言，應該僅有一個引起它變化的原因。

      為什麼要這樣做呢？因為每一個職責都是變化的一個軸線。當需求變化時，反映出來的就是類的職責的變化。如果一個類承擔多個職責的話，那麼引起它變化的原因就會有多個。如果一個類承擔多個職責，就等于将這些職責耦合在了一起。一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導緻脆弱的設計，但變化發生時，設計會遭受意想不到的破壞。

      那看一下什麼是【職責】吧！職責在這裡定義為“變化的原因”。如果有不隻一個動機去改變一個類，那麼這個類就不止一個職責。

      下面，還是用例子來說明問題。來看一下代碼：

          interface Modem{

public void dial(String pno);

public void hangup();

public void send(char c);

public void recv();

}

     上面這個接口定義了4個方法，其中有兩個職責：一個是連接配接管理；一個是通信管理。那麼，這裡到底需不需要分離職責呢？就是将這個接口分為兩個接口。

     對于這個問題，是否分離的關鍵在于應用程式的變化方式！如果這兩個職責的變化是不同步的，打個比方：關于通信的職責經常方式變化，而關于連接配接的職責則是比較穩定的。這樣，就需要分離職責了。如果這兩個職責的變化經常是同時發生的，那麼就不需要分離職責了！

     總之，就是變化的軸線僅當變化實際發生時才有具有真正的意義。也可以說在任何變化發生之前，任何原則的實施都是不明智的，因為我們無法猜測變化。

     對于這個原則有一個違反SRP的特殊情況：持久化。因為持久化的職責不會經常變動，是以可以将持久化的一系列職責都放在一個類中。其實這也就是所謂的“具體問題，具體分析”。