單一職責模式並不難懂，我們用一個例子來學習一下。

設計一個手機上的俄羅斯方塊的遊戲，比如用WinForm開發的話，我們需要：

首先建立一個窗體Form，然後加一個用於遊戲框的控制元件，比如Panel，一個按鈕來控制開始，最後放一個Timer控制元件用於分時動畫的程式設計。寫程式碼當然是編寫Timer_Tick事件來繪出和擦除方塊，並作出堆積和消層的判斷。再編寫控制元件的鍵盤事件，按了左箭頭則左移，右箭頭則右移等等。對了，還需要用到些GDI+技術的方法來畫方塊與擦方塊。

如果寫到一個Form類中，我們可以發現這個程式根本沒法複用。比如移植到PC端上，就需要很多修改，

我們發現遊戲邏輯與介面是沒關係的，我們應該把他們分開。

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

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

方塊的可移動的遊戲區域，可以設計為一個二維陣列來表示，方塊的移動就是陣列的下標變化，堆積的話判斷array[x,y+1]是否等於1，消層的話array[x,y]迴圈從x由0到9，判斷array[x,y]是否都等於1，是的話資料清零，並將其上方的陣列值遍歷下移一位，

這裡我們可以發現，所謂遊戲邏輯，不過就是陣列每一項值變化的問題，下落，旋轉、碰撞判斷，移動，堆積這些都是在陣列具體項的值的變化。而介面表示邏輯，不過是根據陣列的資料進行繪出和擦除，或者根據鍵盤的命令呼叫陣列的相應方法進行改變，因此，至少應該考慮將次程式分為兩個類，一個是遊戲邏輯的類，一個是窗體的類。當有一天要改變介面，或者換介面時，不過是窗體類的變化，與遊戲邏輯無關，以達到複用的目的。

軟體設計真正要做的許多內容，就是發現職責並把職責相互分離，如果你能夠想到多於一個的動機取改變一個類，那麼這個類就具有多於一個的職責。