设计原则之单一职责原则

单一职责原则

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

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

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

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.变更引起的风险降低

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

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值