S- Single Responsibility Principle(SRP)單一職責原則
引：只有佛自己有道破玄機的責任。
單一職責表現爲“強聚集”(cohesion)，不應該有一個以上的原因修改一個類。
例如一個保齡球小遊戲，可以用一個"Game"類處理兩個單獨的職責。一個是保持現在框架的軌跡，另一個是計算分數，但最後它被拆成了兩個類。因爲每個職責是類修改的一個基準線，當需求改變時，它通過改變類的職責表現出來。如果一個類有多於一個的職責，它將有多於一個的原因改變。當修改其中一個職責時有可能會影響到其它職責的實現，它會使設計變得脆弱。
在這裏“職責”被定義爲“導致改變的原因”，如果我們可以想到多於一個原因導致一個類的改變，那麼這個類就多於一個職責。但這有時很難看清楚。我們習慣以組的形式思考職責。例如我們想到“Modem"的接口如下，大部分人會認爲這些接口看起來是合理的。這四個函數聲明確實屬於一個調試解調器。
interface Modem
{
public void dial(string pno);
public void hangup();
public void send(char c);
public char recv();
}
但是，這裏看到了兩個職責。第一個是連接管理，第二個是數據通信。dial和hangup函數管理調試解調器的連接，而send和recv傳輸數據。這兩個職責應該分開嗎？答案是肯定的。這兩組函數幾乎沒有共同之處，它們會因爲不同的原因改變。因此，下面的設計也許會好些。它將兩個職責拆分成兩個接口，它至少使應用程序不再擁有兩個職責。
但是還是把兩個職責放到了單一的類ModemImplementation中，這不是想要的，但可能是必須的。這往往與硬件或操作系統的細節有關，強迫我們連接一些我們不想要的職責。然而，通過拆分接口，至少相對於其它應用我們將職責分開了。我們也可以把這個類看成一個組合。
結論：SRP是最基本的原則之一，但也是最難使用的一個。我們經常很自然地把職責連接在一起。發現和拆分這些職責是軟件設計要做的重要工作之一，其它原則也會跟它相關。
單一職責原則（SRP），就一個類而言，應該僅有一個引起它變化的原因。
如果一個類承擔的職責過多，就等於把這些職責耦合在一起，一個職責的變化可能會削弱或抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當發生變化時，設計會遭到意想不到的破壞。
軟件設計真正要做的許多內容，就是發現職責並把那些職責相互分離。其實要去判斷是否應該分離出類來，也不難，那就是如果你能夠想到多於一個動機去改變一個類，那麼這個類就具有多於一個的職責，就應該考慮類的職責分離。
編程時，我們要在類的職責分離上多思考，做到單一職責，這樣你的代碼纔是真正的易維護、易擴展、易複用、靈活多樣。
