设计原则之单一职责原则

单一职责原则

什么是单一职责原则
定义：有且仅有一个使接口或类产生变化的原因。

也就是说我们使类或接口变化，只能有一个理由。但是在实际开发的过程中，我们很容易做到接口单一职责，很难做到类单一职责。

例如：我们以查询数据，处理数据，返回数据为例。
如果我们这样设计一个接口：

public interface IUserBO{
    List selectData();
    List dataProcessing();
    List returnData();
}
public class UserBo{
	doSomething...
}

你考虑它的实现类，要做三件事情，分别是查询，处理，返回数据，这样一来，当查询的数据改变时，整个类的另外两个方法也可能会需要改变，
那么这就不符合单一职责原则了吗。当然这里所说的单一职责，也应该用于方法，
例如：某个方法就是用于查询数据的，另外一个方法就只用于处理得到的数据。
但是我们把这个接口设计成符合单一职责原则时：

public interface UserDao{
    List selectData();
}

public interface UserService{
    List dataProcessing();
}

public interface UserController{
    List returnData();
}

这不就是我们熟悉的三层架构吗? 我这里所讲的是在MVC模式的意义上，Dao层可以说它的职责就是与数据库交互，service层的职责就是
处理DAO层返回的数据，而Controller层的职责就是与页面交互。
当然有的人会反驳我，说Controller层的职责是接收请求，和返回响应 ，这也就是我们在项目中有可能违背单一职责原则的原因有二：
1.如果完全遵循单一职责原则，那么我们的系统类的复杂度会变高。
2.每个人对于职责划分的理解不同，A可以把与数据库交互认为是一种职责，但是B可以认为在与数据库交互的过程中，查询是一种职责，修改是另一种职责，新增又是一种职责…

当然，单一职责原则还是有优点的：

1.类的复杂性降低，实现什么职责都有明确的定义
2.可读性提高
3.可维护性提高
4.变更引起的风险降低

所以对于单一职责原则，设计模式之禅的作者就建议了：在设计时，接口一定要做到单一职责原则，而类的设计尽量做到单一职责原则。