就一个类而言，应该仅有一个引起它变化的原因[ASD]。
从俄罗斯方块说起，我们先写一个PC版的俄罗斯方块，把所有代码写在Form中，包括随机产生方块，定时方块下落一格，判断是否到底，到底后判断是否可消除一行。另一方面，接收游戏者的按键输入，决定方块左右移动、旋转、加速下落。这样设想应该是没有问题的，但再想到如果要把这个俄罗斯方块移到手机上，我们只有改变整个代码，拷贝、粘贴到新的程序中。“这当中，有些东西是始终没变的。如下落、旋转、碰撞判断、移动、堆积这些游戏逻辑，和界面如何表示没有什么关系，为什么要写在一个类里面呢？”
如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其它职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。
软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。其实要去判断是否应该分离出类来，也不难，那就是如果你能够想到多于一个的动机去改变一个类，那个这个类就具有多于一个的职责，就应该考虑类的职责分离。
设计一个游戏，随机生成一个三位数A，然后让用户输入三位数B，如果A与B相等提示成功。否则提示A与B数字相同的个数，以及A与B的位置相同数字也相同的个数。然后再让用户输入，再提示，直到成功为止。
如随机生成349，用户输入123，提示1，0，用户再输入456，提示1，0，用户再输入789，提示0，1，用户再输入149，提示2，1……
全部用一个类的方式来体现。game1.cs
这种代码的问题是，如果要把这个游戏要放到界面上去，这些代码只能通过拷贝的方式来转移，显然拷贝完后，假设我们对某个功能加强了，要去两个地方修改，非常有问题。
现在第二个任务，让猜数字游戏支持命令提示符方式与界面方式。实现这个任务其实也可以使用子程序的方法，但C#不允许把子程序单独存放，一定要放到类里面，我们就放在一个类里面，全部都是使用静态方法。
添加一个界面，放四个文本框，再加上一个按钮，第一个文本框显示计算机随机产生的数据（测试时），第二个文本框与第三个文本框显示判断的结果数字相同的个数与位置也正确的个数，第四个文本框让用户输入猜想的结果，点击按钮则表示提交。
现在要更改game类的原因都是因为game的游戏规则变化才去更改。
一个类只有一个引起它变化的原因，即使是子程序，也是这种原则，一个子程序，如果多种不同性质的因素都要导致更改这个子程序，它是否意味着说它承担的功能太强了。职场上，一个人承担的功能太强，导致他忙忙碌碌。一个问题被卡住了，其它不相关的问题也因此被卡住了。太强的子程序体现在，过多的入口参数，我有二十几个入口参数的子程序。无法说明出子程序功能。无法提供充足的测试用例的。在完全不相干环境下使用这个子程序。
所以不能把单一职责原则归到对象才有。
