单一职责原则
什么是单一职责原则
定义:有且仅有一个使接口或类产生变化的原因。
也就是说我们使类或接口变化,只能有一个理由。但是在实际开发的过程中,我们很容易做到接口单一职责,很难做到类单一职责。
例如:我们以查询数据,处理数据,返回数据为例。
如果我们这样设计一个接口:
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.变更引起的风险降低
所以对于单一职责原则,设计模式之禅的作者就建议了:在设计时,接口一定要做到单一职责原则,而类的设计尽量做到单一职责原则。