设计模式6大设计原则解读——单一职责原则

在Java软件开发领域，熟练掌握6大设计原则及23种设计模式，是从初级软件工程师进阶到中级甚至高级软件工程师必备的技能之一，当然，仅仅了解6大设计原则及设计模式还远远不够，能将设计原则及设计模式熟练应用到企业软件开发的过程中，并能解决企业软件中实际产生的问题，这样才算达到了一定的目的。软件本身不产生价值，技术本身也不产生价值，实际创造的价值是在用户使用软件产品解决现实问题的时候才能体现出来。将设计原则及设计模式灵活并巧妙的应用在软件之中，根据不同领域中不同的业务实际的应用场景采用合适的设计模式才能开发出稳定、易扩展、性能好、质量高的软件产品。言归正传，下面我们来说说6大设计原则。

1. 单一职责原则（Single Responsibility Principle）
   定义：不要存在多于一个导致类变更的原因。简称SRP原则。
   原文定义：There should never be more than one reason for a class to change.
   简要解读： 通俗的说，即一个类只负责一项职责。 对一个类而言，应该只有一个引起它变化的原因。
   场景再现：现在有一个类C（Class）负责两个不同的职责：职责P1(Principle1)，职责P2(Principle2)。当由于职责P1(Principle1)需求发生改变而需要修改类C（Class）时，可能会导致原本运行正常的职责P2(Principle2)功能发生故障。
   解决方案：使用单一职责原则 分别建立两个类C1（Class1）、C2（Class2），使C1完成职责P1，C2完成职责P2。原本由C类完成的职责P1和职责P2经过使用SRP原则，很好的将职责P1和P2分开到不同的类C1和C2当中去执行，这样一来，当修改类C1时，不会使职责P2发生故障风险；同理，当修改C2时，也不会使职责P1发生故障风险。这样就达到了单一职责的目的。
   理解：单一职责原则有很多争议，主要是针对职责的定义，什么是类的职责？又如何去划分类的职责？在实际应用过程中很难明确划分。在实际coding中，谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。虽然单一职责原则如此简单，并且被认为是常识，但是即便是经验丰富的工程师写出的程序，也会有违背这一原则的代码存在。为什么会出现这种现象呢？因为有职责扩散。所谓职责扩散，就是因为某种特殊原因，职责P被分化为粒度更细的职责P1和P2。
   单一职责原则是实现高内聚、低耦合的指导原则，虽然简单却也是最难运用的一个原则。下面我们通过一个例子来说明单一职责原则：在开发过程中，大家都该接触过用户、角色管理、机构管理等模块，使用的无非是RBAC模型（Role Based Access Control）基于角色的访问控制，通过分配和取消角色来完成用户权限的控制，使动作主体（用户）与资源（权限）相分离。复杂的权限管理也是基于RBAC模型增加了其他业务模型从而形成的权限控制。我们这里来说用户管理、修改用户信息、增加组织机构、增加角色等，用户有很多动作和行为需要进行维护，先来设计一个反例，类图如下：
   

   大家很容易看出这个类图设计的问题所在，用户的属性和行为没有分开，应该把用户信息抽取成一个BO（Business Object，业务对象），把用户行为抽取一个Biz (Business logic，业务逻辑),修改之后类图如下：
   

   修改之后的类图拆成了两个接口，IUserBO负责用户属性，它的职责就是收集和反馈用户的属性信息。IUserBiz负责用户的行为，完成用户信息维护和变更。
   下图是项目中经常采用的SRP类图：
   

在实际开发中，遵循SRP原则也要注意不要人为的增加设计的复杂性，我们设计程序是面向接口的编程，而不是把类的实现公开给用户，注意不要引起类之间耦合过重、类数量增加这些问题。

下面来总结一下遵循单一职责原则的好处：
1、类的复杂性降低，实现的职责都有清晰明确的定义
2、可读性增强，设计的类、接口、方法职责清晰的情况下，就使程序更加易懂
3、可维护性增强，可读性好的程序更便于维护
4、变更引起的风险降低，程序的可维护性、可扩展性得到了很好的保证

职责的划分没有量化的标准，不要为了完全遵循SRP原则而制造出其他的麻烦，具体的衡量要根据具体项目进行具体分析。需求是在变化的，在应用SRP原则的时候需要考虑项目的可变因素和不可变因素，以及相关收益成本比率情况。对于接口的设计一定要做到单一，类的实现要根据业务复杂情况等综合考虑，原则是死的，人是活的。尤其从国内软件的开发现状来看，项目的开发要受到各方面因素的影响，比如工期、成本、开发人员技术水平、硬件、网络等条件的制约，所以SRP原则不一定被完全刻板的使用，尽量做到只有一个原因能引起一个类的变化就已经非常不错了。

这就是对单一职责原则的简单解读，希望大家好好体会这一原则的使用。