6大设计原则-单一职责

单一职责原则

1.单一职责原则的英文名称是Single Responsibility Priniciple,简称SRP。
通俗一点说,每个类只负责单一的职责,让类所需要处理的事情更明确,但是这个职责的划分要根据具体的情况去处理。
定义:有且仅有一个原因引起类的变更。
There should never be more than one reason for a class to change

例子:用户,部门,角色管理模块,这是常见的一种场景,基本都是用RBAC模型(role-based access control,基于角色的访问控制,通过分配和取消角色来完成用户权限的授予和取消,使动作主体(用户)和资源行为(权限)分离)。我们这里要用的是用户管理,修改用户信息,修改部门,修改角色,用户有这么多信息和行为需要维护,直接写到一个接口中,类图1-1:

1-1

这个接口把用户的属性和用户的行为没有分开,至少应该把用户信息抽取成一个BO(Business Object,业务对象),把行为抽取成一个Biz(Business Logic,业务逻辑)(这应该是 对应我们常用的user的po和业务相关的service);按照这个思路对类图修正,如2-2:
1-2

这个就是把用户的属性和行为分开了,用面向接口的做法去实现,通过userInfo既可以当做属性类也可以当成行为类;
这个感觉接口按职责分开了,但是实现类还是糅合了两个职责);
我们实际更倾向于(这个就有点接近实际开发的结构)图1-3
1-3

通过单一职责来分析电话的通话:拨号,通话,回应,挂机
基本接口图1-4:
1-4

这个接口好像是很接近单一原则,好像是只实现了通话的功能,但实际又可以分为协议管理(接通,挂机)和数据传输(通话),这可能协议改变和数据传输方式(上网)改变都会引起类的变化,那就考虑拆分两个接口,图1-5:
1-5

这样做很符合单一职责,但是我们要创建一个Phone就需要通过组合协议类和数据传输类的方式创建,在根据实际的情况去优化一下,图1-6:
1-6

这个手机通过实现两个接口,任何一个接口有修改,实现类phone都会有改动,只是接口之间不影响,那这个类好像不太符合,有点不太明白这个例子
单一职责适用于接口、类,同时也适用与方法,这个在平时的工作中时体会比较深,在dao层也有很好的体现,不要在dao层写业务逻辑,只做对应的数据操作sql,当需求有改动也就可以只改动对应的地方,而不是在一个方法中写完所有的业务逻辑,可读性也很差,过段时间就自己看懵了,用比较官方的语言说单一原则的好处:

  1. 类的复杂性降低了,明确清晰的定义指责
    对指责的划分需要没有一个量化的标准,都是根据实际情况灵活处理
  2. 可读性提高了,毕竟单一嘛,复杂度降低了
  3. 可维护性提高,还是因为单一职责,耦合性较低,不会影响到其他的接口实打实的好处,可以看出一个好的设计对后期的影响有多大
  • 在平时的工作中,类的单一职责还没有明显的感觉,明显的就是业务和实体的区分,但是往往一个service会做很多的功能,但是service中的方法单一职责感觉很明显,不仅可以提高代码的可读性,而且方法职责分的好的话,可以复用,也就是常说的重复的代码抽出一个公共方法
  • 在实际的开发中还需要从具体场景考虑,没有必要刻意的去追求满足这些原则去人为的增加设计的复杂性,只有最合适的才是最好的设计

内容来自《设计模式之禅》

你可能感兴趣的:(6大设计原则-单一职责)