设计模式之单一职责原理

设计模式之单一职责原理

1、定义

单一职责原则（SRP）：就一个类而言，应该有且只有一个引起它变化的原因。
如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会消弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，但变化发生时，设计会遭遇到意想不到的破坏。

2、实例

方块游戏的设计：
分析那些是游戏的界面，那些是游戏逻辑，然后进行分离游戏的可移动区域可以设计为一个二维整型数组来表示坐标，宽10，高20，比如“int[,] arrySquare=new int[10,20]”,那么整个方块的移动实际上就是数组的下标变化，比如原方块在arrySquare[3,5]上，则下移变成arrySquare[3,6],如果下移的同时按下了左键，则变为arrySquare[2,6]。每个数组的值就是是否存在方块的标志，存在为1，不存在时缺省为0。判断能否左移就是判断arrySquare[x,y]中的x-1是否小于0，否则arrySquare[x-1,y]是否等于1，否则说明左侧有方块。所谓堆积，不过是判断arrySquare[x,y+1]是否需等于1的过程，如果是，则将arrySquare[x,y]的值改为1，那么消层，就是arrySquare[x,y]种循环0到9，判断arrySquare[x,y]是否都不等于1，是则此行数据清零，并将其上方的数组值遍历下移一位。
所以，所谓游戏逻辑，不过是数组的每一项的值变化的问题，下落，旋转，碰撞判断，移动，堆积。

3、单一职责原则的优点

1. 可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；
2. 提高类的可读性，提高系统的可维护性；
3. 变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。

4、使用单一职责原则

1. 单一职责最难划分的就是职责。
2. 单一职责原则提出了一个编写程序的标准，用职责和变化原因来衡量接口或类设计的是否优良，但是职责和变化原因都是不可度量的，因项目而异，因环境而异。
3. 接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。