单一职责原则（Single Resposibility Principle）
定义：一个类应该有且仅有一个变化的原因
这里的变化是指修改代码，如修复bug，功能不满足修改等等，也就是说你修改了一个方法的代码，不能导致其他方法的代码也需要修改
具体做法：将不同的职责封装到不同的独立类中
为什么要封装到不同的独立类中?是由于每个职责都是一个变化点。当需求发生变化时，这个变化通过更改职责相关的类来体现
例如：数据库将连接数据库和执行sql分开到两个类中，一个只负责和数据库连接，一个只负责操作sql
实际应用：
如WEB应用分了controller service dao
dao--只针对书库
service-只负责业务
controller--负责和外界交互
大家发现，我们有很多controller 很多service很多dao，是的我们每个表是不是要对应一个dao，一个service
1.根据职责不同结构上的划分
2.一张表一个DAO
3.同一个service中的方法不互调，因为每个细分又是不同职责，一个代码的变更可能引起其他的功能无法使用或者修改
有人估计要说，那DAO层的crud为什么不单独隔离到独立的类中，crud操作数据的这几个接口基本上不会变化，变化的也就是表，表变化，mapper文件的sql要修改，对应的实体类要修改
有点：
1.提高类的可读性和可维护性
一个类的职责少了，复杂度就降低了，代码 就少了，可读性就提高了，可维护性就自然提高了
2.提高系统的可维护性
一个系统是由各个类组成的，如果每个类的可维护性高了，系统的可维护性自然也高了
3.降低了变更的风险
一个类的职责越多，变更的可能性就越大，变更带来的风险就越高
合理的职责分解：
相同的职责放在一起，不同的职责分解到不同的接口和实现中去，这个是最容易也是最难运用的原则，职责有时候不好划分或者不经意间就违反了单一职责原则，
关键是要从业务出发，从需求出发，识别出同一种类型的职责
