设计模式-单一职责原则

    单一职责原则是指让一段代码的功能最细化并单一化，就是让它只专一于干一件事。主要是为了实现解耦，并让代码的维护性和可读性更强。

    解耦是在程序设计中最重要的一个黄金法则，单一职责原则也是为了实现解耦的一种设计思想。若是一个单位内的代码所承担的职责的种类过多，那么当其中一个职责在未来发生变化的时候，颇有可能会对其余职责的逻辑产生影响。而且这样的一段代码，可读性和维护性都很糟糕。因此经过单一职责原则，把代码的逻辑进一步的拆分到不一样的地方去，让每段的代码都只专一于某一个职责，这样在之后维护起来，也好快速定位。

    我通过的几个项目中，都看到过把各类逻辑功能都塞到了一个实现类里面去。像是请求参数校验、异常处理、各类业务逻辑的检查、构造响应实体等等，这些或是存在同一个类，或是散布在各个方法里。相信你也看到过一个大类或是大方法。每次修改的时候都当心翼翼，生怕坑了别的地方。能够看到诸如此类的功能并不是核心的业务功能，而他们之间互相都没有什么关联，这时候最佳的实践方式是把他们都相互拆离出去。参数校验的就只干参数校验，处理异常的就只处理异常。

    怎么分离，分离到哪里去倒并无一个明确的答案。就拿参数校验来讲，不少接口都须要，而不一样的接口的校验规则是不一样的。好比新增和修改用到了同一个参数bean，而修改的id必需的，新增的id是必不需的（注意和非必需的区别），而新增的一些参数是必需的，而修改则是非必需。如下是几个常见思路：

• 放到一个只作参数校验的工具类里，每一个方法负责不一样的校验
• 业务service类继承一个BaseService类，在BaseService里写一个校验的方法。至于一个方法怎么应对不一样的校验策略，这个能够用以前说到的工厂模式或策略模式实现，又或是经过方法的参数动态实现校验的动态
• 集成第三方库。好比参数校验能够用到支持Bean Validation（JSR-303）的hibernate validator

    须要注意的是也不能过分分离，就像不能过分设计同样。我认为当一个代码单位里出现了不少互不相干的逻辑代码是属于不正常的。我之因此说代码单位是由于从system->module->service->class->method这样的层次下来，站在不一样的层次描述的意义是有不一样的。不可避免的有一些逻辑互相有关联，那最好仍是不要拆分了，放在一块儿代码反而更流畅。所幸这样的状况不多。

    不必强迫症似的必定要拆分的精细到单个单个的功能块，或者是一个方法不能多少行之类的。