一、单一职责原则
1、大多数时候，一件产品简单一些，职责单一一些，或许是更好的选择。这就和设计模式中的一大原则——单一职责的道理是一样的。
2、就一个类而言，应该仅有一个引起它变化的原因。
3、我们在做编程的时候，很自然地就会给一个类加各种各样的功能，比如我们写一个窗体应用程序，一般都会生成一个Form1这样的类，于是我们就把各种各样的代码，像某种商业运算的算法呀，像数据库访问的SQL语句呀什么的都写到这样的类当中，这就意味着，无论任何需求要来，你都需要更改这个窗体类，这其实是很糟糕的，维护麻烦，复用不可能，也缺乏灵活性。
4、单一职责原则（SRP）：就一个类而言，应该仅有一个引起它变化的原因。
二、方块游戏的设计
1、方块下落动画的原理是画四个小方块，擦掉，然后再在下一行画四个方块。不断地绘出和擦掉就形成了动画，所以应该要有画和擦方块的代码。然后左右键实现左移和右移，下键实现加速，上键实现旋转，这其实都应该是函数，当然左右移动需要考虑碰撞的问题，下移需要考虑堆积和消层的问题。
2、如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。事实上，你完全可以找出哪些是界面，哪些是游戏逻辑，然后进行分离。
3、那你就应该明白了，所谓游戏逻辑，不过就是数组的每一项值变化的问题，下落、旋转、碰撞判断、移动、堆积这些都是在做数组具体项的值的变化。而界面表示逻辑，不过是根据数组的数据进行绘出和擦除，或者根据键盘命令调用数组的相应方法进行改变。因此，至少应该考虑将此程序分为两个类，一个是游戏逻辑的类，一个是WinForm窗体的类。
4、软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。
5、如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责，就应该考虑类的职责分离。
6、界面的变化是和游戏本身没有关系的，界面是容易变化的，而游戏逻辑是不太容易变化的，将它们分离开有利于界面的改动。
三、手机职责过多吗？
1、整合当然是一种很好的思想。比如Google最初的理想就是将一切的需求都整合到一个文本框里提交，用干净的页面来吸引用户，导致互联网的一场变革。但现在分类信息、垂直搜索又开始流行，这却是单一职责的思想体现。
2、总的来说，手机的发展有它的特点，而编程时，我们却是要在类的职责分离上多思考，做到单一职责，这样你的代码才是真正的易维护、易扩展、易复用、灵活多样。
（完）
