单一职责原则是指让一段代码的功能最细化并单一化，就是让它只专注于干一件事。主要是为了实现解耦，并让代码的维护性和可读性更强。
解耦是在程序设计中最重要的一个黄金法则，单一职责原则也是为了实现解耦的一种设计思想。如果一个单位内的代码所承担的职责的种类过多，那么当其中一个职责在将来发生变化的时候，很有可能会对其他职责的逻辑产生影响。并且这样的一段代码，可读性和维护性都很糟糕。所以通过单一职责原则，把代码的逻辑进一步的拆分到不同的地方去，让每段的代码都只专注于某一个职责，这样在以后维护起来，也好快速定位。
我经过的几个项目中，都看到过把各种逻辑功能都塞到了一个实现类里面去。像是请求参数校验、异常处理、各种业务逻辑的检查、构造响应实体等等，这些或是存在同一个类，或是散布在各个方法里。相信你也看到过一个大类或是大方法。每次修改的时候都小心翼翼，生怕坑了别的地方。可以看到诸如此类的功能并非核心的业务功能，而他们之间互相都没有什么关联，这时候最佳的实践方式是把他们都相互拆离出去。参数校验的就只干参数校验，处理异常的就只处理异常。
怎么分离，分离到哪里去倒并没有一个明确的答案。就拿参数校验来说，很多接口都需要，而不同的接口的校验规则是不同的。比如新增和修改用到了同一个参数bean，而修改的id必需的，新增的id是必不需的（注意和非必需的区别），而新增的一些参数是必需的，而修改则是非必需。以下是几个常见思路：
- 放到一个只做参数校验的工具类里，每个方法负责不同的校验
- 业务service类继承一个BaseService类，在BaseService里写一个校验的方法。至于一个方法怎么应对不同的校验策略，这个可以用之前说到的工厂模式或策略模式实现，又或是通过方法的参数动态实现校验的动态
- 集成第三方库。比如参数校验可以用到支持Bean Validation（JSR-303）的hibernate validator
需要注意的是也不能过度分离，就像不能过度设计一样。我认为当一个代码单位里出现了很多互不相干的逻辑代码是属于不正常的。我之所以说代码单位是因为从system->module->service->class->method这样的层次下来，站在不同的层次描述的意义是有不同的。不可避免的有一些逻辑互相有关联，那最好还是不要拆分了，放在一起代码反而更流畅。所幸这样的情况很少。
没必要强迫症似的一定要拆分的精细到单个单个的功能块，或者是一个方法不能多少行之类的。