单一职责模式并不难懂，我们用一个例子来学习一下。
设计一个手机上的俄罗斯方块的游戏，比如用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，是的话数据清零，并将其上方的数组值遍历下移一位，
这里我们可以发现，所谓游戏逻辑，不过就是数组每一项值变化的问题，下落，旋转、碰撞判断，移动，堆积这些都是在数组具体项的值的变化。而界面表示逻辑，不过是根据数组的数据进行绘出和擦除，或者根据键盘的命令调用数组的相应方法进行改变，因此，至少应该考虑将次程序分为两个类，一个是游戏逻辑的类，一个是窗体的类。当有一天要改变界面，或者换界面时，不过是窗体类的变化，与游戏逻辑无关，以达到复用的目的。
软件设计真正要做的许多内容，就是发现职责并把职责相互分离，如果你能够想到多于一个的动机取改变一个类，那么这个类就具有多于一个的职责。