對于一個類，應該僅有一個引起它變化的原因，很簡單，如果一個類承擔了多余一個的職責，那么引起它變化的原因就會有多個。也就等于把這些職責耦合在了一起。當然了一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。最終的結果就是這種耦合會導致一種脆弱的設計。例子：Retangle類有兩個方法。一個方法把矩形繪制在窗體上，另一個方法計算矩形的面積:

                            多余一個的職責的情況
    有2個不同的程序使用矩形類，一個是計算幾何學方面的，此時Rectangle類會為次幾何學程序提供幫助，它從來是不會在窗口上繪制矩形的。而另一個程序是有關圖形學方面的，他可能也會進行一些幾何學方面的計算，但是它肯定會在窗口上繪制矩形。
        所以說這個設計違反了單一職責原則，就是矩形類具有2個職責：1：提供了一個矩形幾何形狀的數(shù)學模型；2：把矩形的一個圖形用戶界面繪制出來。這樣的設計可能會導致一個地方的改動會帶動其他的地方的一列改動。一個比較好的設計是把這兩個職責分離到兩個完全不同的類中。如下：

  什么是職責？
可以理解為：變化的原因，如果你能想到多與一個的動機去改變一個類，那么這個類就具有多于一個的職責。有時候我們很難做到這一點，都是習慣以組的方式去考慮職責。如下面的接口看起來很合理：該接口所聲明的4個函數(shù)確實是調制解調器所具有的功能：

        然而，該接口中卻顯示出兩個職責，第一個職責是連接管理[dial；hangUp]；第二個職責是數(shù)據(jù)通信[send；recv ]，問題是這兩個職責應該被分開嗎？這得依賴于應用程序變化的方式了。如果程序的變化會影響連接函數(shù)的簽名，那么這個設計就具有僵化性的味道。因為send；recv類必須要重新編譯。部署的次數(shù)常常會超過我們希望的次數(shù)。在這樣的情況下，需要把這兩個職責分離開。但是另一方面，如果應用程序的變化方式總是導致這兩個職責的同時變化，那么就不必分離他們了。
總結：單一職責是所有原則中最簡單的之一，也是最難正確運用之一。我們會自然的把職責結合在一起，軟件設計真正要做的許多內容，就是發(fā)現(xiàn)職責并把那些職責相互分離。