设计模式｜理解单一职责原则
软件质量保障
专注测试圈，自动化测试、测试平台开发、测试新技术、大厂测试岗面经分享， 可以帮忙内推BATJ等大厂！欢迎加VX沟通交流: ISTE1024
很早想总结一些关于设计模式的文章了，回头看一下几年前写的代码，简直不忍直视。也能理解，毕竟当初校招选择测试岗位也是为了逃避“写代码”嘛，但是谁能想到，当下测试行业大环境，不会编程的测试简直无法生存。亏我的思想觉悟比较高，认识到编程的重要性后就狂补了一些开发“基础”，例如Java、spring mvc这些知识，不能说专业吧，最起码也是运用自如，能实现自己的ideas。
意识到设计模式的重要性是在前东家负责接口测试框架的时候，当时就买了《设计模式之禅》这本书，然后大概刷了一遍（重点学习了工厂模式、代理模式、建造者模式），在设计框架的时候还真的起到了效果。
最近再次重温这本书，感慨颇多，接下来的日子里我就以自己的理解结合书中的知识点不定期给大家分享一些设计模式的知识，所写内容纯属个人理解，如有出入，请各位同行批评指正，不吝赐教。
通俗理解设计模式，它描述了在软件设计过程中的一些不断重复发生的问题，以及该问题的解决方案。也就是说，它是解决特定问题的一系列套路，是软件界前辈们的代码设计经验的总结，具有一定的普遍性，可以反复使用。其目的是为了提高代码的可重用性、代码的可读性和代码的可靠性。我称设计模式是程序员编程需要具备的思想，也就是说大家写代码前先思考自己的业务是否能够按设计模式要求来实现。（当然对于简单的程序开发，写一个简单的算法要比引入某种设计模式更加容易。但对大项目的开发或者框架设计，用设计模式来组织代码显然更好。）
《设计模式之禅》这本书分三大模块，6大设计原则，23大设计模式以及设计模式PK，此系列文章主要分享前两大模块内容，每篇文章分享一个设计模式知识点。本文算是个开头，分享一下 6大设计原则中的 单一职责原则 。
定义
单一职责原则（Single Responsibility Principle，SRP），规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分（There should never be more than one reason for a class to change）。
案例
做过管理系统项目的同学肯定都接触过用户、机构、角色管理这些模块，实现方式都是基于RBAC模型（Role-Based Access Control，基于角色的访问控制，通过分配和取消角色来完成用户权限的授予和取消，使动作主体（用户）与资源的行为（权限）分离）。如果我们将用户管理、修改用户信息、增加角色等涉及到一个接口中，可以看一下其实现类图如下所示。
当然了，如果你是开发，可能也看出问题了，即用户属性和用户行为没有分开设计。也就是说，接口的职责并不是单一的，而是包含两个职责（功能），用户属性和用户行为。
如果基于单一职责原则，应该把用户信息抽取成一个BO（Business Object，业务对象），把行为抽取成一个Biz（Business Logic，业务逻辑），参考改进后的类图。
重新拆成两个接口，IUserBO负责用户的属性，简单地说，IUserBO的职责就是收集和反馈用户的属性信息；IUserBiz负责用户的行为，完成用户信息的维护和变更。
优点
▪ 类的复杂性降低，实现什么职责都有清晰明确的定义；
▪ 可读性提高，复杂性降低，那当然可读性提高了；
▪ 可维护性提高，可读性提高，那当然更容易维护了；
▪ 变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。
最佳实践
单一职责原则适用于接口、类的同时也适用于方法。一个方法尽可能只做一件事情。例如修改密码这个方法，尽量不要把它放到“修改用户信息”方法中。下图类图定义了changeUser方法，承担了多个职责。
而基于单一职责原则，下图类图中单个方法只承担一个职责。
所以，如果对接口、类、方法使用了单一职责原则，项目组成员可以轻松而又愉快地进行开发，可以减少了无谓的人员和资金消耗。
对于单一职责原则，建议是接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。
附录
UML类图介绍：http://www.uml.org.cn/oobject/201610282.asp
内推福利
社招需要内推的可以直接联系我or私信我（VX: ISTE1024）
往期推荐
