标签：style blog ar color sp strong on 数据 div
单一职责原则，就一个类而言，应该仅有一个引起它变化的原因。
现在比如说要写一个俄罗斯方块，怎么能实现功能的代码复用呢?
不管怎么样游戏中的有些东西是始终没有变化的，比如说下落、旋转、碰撞判断、移动、堆积这些游戏的逻辑是没有变化的。这些都是和游戏有关的逻辑，和界面如何没有什么关系。
如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，设计会遭受到意向不到的破坏。
软件设计真正要做的许多的内容就是发现职责，并把那些职责相互分离。
下面就写一个完整的俄罗斯方块的游戏：
第一步：游戏逻辑分析
方块的可移动区域，可以设计为一个二维整型的数组用来表示坐标，比如说宽10高20，则：
int[][] arraySquare = new int[10][20];
|
整个方块的移动其实就是数组下标的变化，比如说原方块在arraySquare[3][5]上，则下移时就变成arraySquare[3][6]，如果下移的同时还按下了左键，就是arraySquare[2][6]。 每个数组的值就是是否存在方块的标志，存在为1，不存在时缺省为0。 所以碰撞检测： 是否能左移就是判断arraySquare[x][y]中的x-1是否小于0，否则就碰撞了。或者arraySquare[x-1][y]是否等于1，否则就说明左侧有堆积的方块。 所谓堆积，不过是判断arraySquare[x][y+1]是否等于1的过程，如果是则将自己arraySquare[x][y]的值修改为1。 那么消层，就是arraySquare[x][y]中循环由0到9，判断arraySquare[x][y]是否都等于1，是则次行数据清零，并将其上方的数组值遍历下移一位。 |
所谓游戏逻辑，不过是数组的每一项值变化的问题，下落、旋转、碰撞检测、移动、堆积这些都是在做数组具体项的值的变化。
而这部分游戏的逻辑，代码是可以复用的。
[未完，待续……]
标签：style blog ar color sp strong on 数据 div
原文地址：http://www.cnblogs.com/stemon/p/4167818.html
