单一职责原则
1.单一职责原则的英文名称是Single Responsibility Priniciple，简称SRP。
通俗一点说，每个类只负责单一的职责，让类所需要处理的事情更明确，但是这个职责的划分要根据具体的情况去处理。
定义：有且仅有一个原因引起类的变更。
There should never be more than one reason for a class to change
例子：用户，部门，角色管理模块，这是常见的一种场景，基本都是用RBAC模型（role-based access control，基于角色的访问控制，通过分配和取消角色来完成用户权限的授予和取消，使动作主体（用户）和资源行为（权限）分离）。我们这里要用的是用户管理，修改用户信息，修改部门，修改角色，用户有这么多信息和行为需要维护，直接写到一个接口中，类图1-1：
1-1
这个接口把用户的属性和用户的行为没有分开，至少应该把用户信息抽取成一个BO（Business Object，业务对象），把行为抽取成一个Biz(Business Logic,业务逻辑)（这应该是 对应我们常用的user的po和业务相关的service）；按照这个思路对类图修正，如2-2：
1-2
这个就是把用户的属性和行为分开了，用面向接口的做法去实现，通过userInfo既可以当做属性类也可以当成行为类；
（这个感觉接口按职责分开了，但是实现类还是糅合了两个职责）；
我们实际更倾向于（这个就有点接近实际开发的结构）图1-3
1-3
通过单一职责来分析电话的通话：拨号，通话，回应，挂机
基本接口图1-4：
1-4
这个接口好像是很接近单一原则，好像是只实现了通话的功能，但实际又可以分为协议管理（接通，挂机）和数据传输（通话），这可能协议改变和数据传输方式（上网）改变都会引起类的变化，那就考虑拆分两个接口，图1-5:
1-5
这样做很符合单一职责，但是我们要创建一个Phone就需要通过组合协议类和数据传输类的方式创建，在根据实际的情况去优化一下，图1-6：
1-6
（这个手机通过实现两个接口，任何一个接口有修改，实现类phone都会有改动，只是接口之间不影响，那这个类好像不太符合，有点不太明白这个例子）
单一职责适用于接口、类，同时也适用与方法，这个在平时的工作中时体会比较深，在dao层也有很好的体现，不要在dao层写业务逻辑，只做对应的数据操作sql，当需求有改动也就可以只改动对应的地方，而不是在一个方法中写完所有的业务逻辑，可读性也很差，过段时间就自己看懵了，用比较官方的语言说单一原则的好处：
-
类的复杂性降低了，明确清晰的定义指责
（对指责的划分需要没有一个量化的标准，都是根据实际情况灵活处理） - 可读性提高了，毕竟单一嘛，复杂度降低了
- 可维护性提高，还是因为单一职责，耦合性较低，不会影响到其他的接口（实打实的好处，可以看出一个好的设计对后期的影响有多大）
- 在平时的工作中，类的单一职责还没有明显的感觉，明显的就是业务和实体的区分，但是往往一个service会做很多的功能，但是service中的方法单一职责感觉很明显，不仅可以提高代码的可读性，而且方法职责分的好的话，可以复用，也就是常说的重复的代码抽出一个公共方法
- 在实际的开发中还需要从具体场景考虑，没有必要刻意的去追求满足这些原则去人为的增加设计的复杂性，只有最合适的才是最好的设计
内容来自《设计模式之禅》
