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

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

一个接口只做同一类事情

一个类只做同一类事情

一个方法只做一件事情

一段代码只做一件事情

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

一、一段代码

?

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

二、一个方法

?

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

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

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

三、一个接口

?

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

举个例子。

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

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

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

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

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

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

?

四、一个类

?

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

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

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

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

欢迎各位童鞋吐槽

?