首页 > 代码库 > 小王和你一起学习系列之设计模式-单一职责原则

小王和你一起学习系列之设计模式-单一职责原则

单一职责原则,从字面上理解就是做一件事情。

单一职责原则应用的场景包括:

一个接口只做同一类事情

一个类只做同一类事情

一个方法只做一件事情

一段代码只做一件事情

咱们具体分析各个应用场景吧

一、一段代码

?

一段代码代表一种逻辑。代码是最细粒度,接口、类、方法都是由代码组成的。

二、一个方法

?

如果方法中的代码逻辑比较简单,哪怕有分支,有不同的逻辑处理,那么也是允许的。如果方法中的代码逻辑很复杂,各种条件判断,如果以后需求发生变更,导致代码发生更改,

修改的时候必然会小心翼翼,生怕改的代码对方法其他代码有影响,让方法产生新的bug。因为方法中的代码是紧耦合的。设计模式要求解耦,内聚。

这个时候就要修改方法,让方法只做一件事情。原来方法中有几个业务逻辑,抽取出来,形成不同的方法(抽取大方法,这是重构_改善既有代码设计中提到的)。本来想找一个代码例子,说明上面的复杂方法,感觉有些生搬硬套,各位童鞋还是结合自己写的项目中的代码来加深理解。

三、一个接口

?

增、删、查、改是我们经常遇到的业务场景。

举个例子。

淘宝网、京东商城都有前台类目的概念。

前台类目的增、删、查、改属于前台类目管理;点击前台类目跳转到后台这属于前台类目的查询逻辑处理。

这是两个没有关联的逻辑,并且两个业务的逻辑处理都很复杂,如果写在一个接口里面,管理起来很麻烦。所以应该分成两个接口来分别管理。

有同学会说了,按照一个接口处理一件事情来说,前台类目管理接口包括增加类目、修改类目、删除类目、查询类目id和code,这是4个业务逻辑,应该分成4个接口。

一个接口只做一件事情,什么才算一件事情,这里面有个划分和度量的问题。

增、删、查、改 虽然属于4个场景,但是每个场景的逻辑不很复杂,并且紧密相关,都属于维护前台类目的操作,可以写在一个接口里面。

?

四、一个类

?

这里的类不是实体类,而指的是接口的实现类

正常情况下,一个接口对应一个接口实现类

比如MVC结构,一个Controller类里面有多个service,每个service代表一个业务逻辑。service就是接口;serviceImpl就是接口的实现类。

如果两个接口逻辑很简单,可以考虑一个类实现多个接口,java里面可以实现多个接口,不能继承多个类。

欢迎各位童鞋吐槽

?

小王和你一起学习系列之设计模式-单一职责原则