（1）Single Responsibility Principle【单一职责原则】

单一职责原则

SRP:Single responsibility principle

 

【概述】单一职责原则又称单一功能原则，面向对象五个基本原则(SOLID)之一。它规定一个类应该只有一个发生变化的原因。该原则由罗伯特・C・马丁(Robert C. Martin)于《敏捷软件开发:原则、模式和实践》一书中给出的。马丁表示此原则是基于汤姆・狄马克(Tom DeMarco)和Meilir Page-Jones的著作中的内聚性原则发展出的。

所谓职责是指类变化的原因。如果一个类有多于一个的动机被改变，那么这个类就具有多于一个的职责。而单一职责原则就是指一个类或者模块应该有且只有一个改变的原因。

【定义】不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。

【原理】

如果一个类承担的职责过多，就等于把这些职责耦合在一起了。一个职责的变化可能会削弱或者一直这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当发生变化时，设计会遭受到意想不到的破坏。而如果想要避免这种现象的发生，就要尽可能的遵守单一职责原则。此原则的核心就是解耦和增强内聚性。

【问题由来】类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。

【产生原因】

没有任何的程序设计人员不清楚应该写出高内聚低耦合的程序，但是很多耦合常常发生在不经意之间，其原因就是：

职责扩散：因为某种原因，某一职责被分化为颗粒度更细的多个职责了。

【解决方案】遵循单一职责原则。将不同的职责封装到不同的类或模块中。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。

虽然单一职责原则如此简单，并且被认为是常识，但是即便是经验丰富的程序员写出的程序，也会有违背这一原则的代码存在。为什么会出现这种现象呢？因为有职责扩散。所谓职责扩散，就是因为某种原因，职责P被分化为粒度更细的职责P1和P2。

比如：类T只负责一个职责P，这样设计是符合单一职责原则的。后来由于某种原因，也许是需求变更了，也许是程序的设计者境界提高了，需要将职责P细分为粒度更细的职责P1，P2，这时如果要使程序遵循单一职责原则，需要将类T也分解为两个类T1和T2，分别负责P1、P2两个职责。但是在程序已经写好的情况下，这样做简直太费时间了。所以，简单的修改类T，用它来负责两个职责是一个比较不错的选择，虽然这样做有悖于单一职责原则。（这样做的风险在于职责扩散的不确定性，因为我们不会想到这个职责P，在未来可能会扩散为P1，P2，P3，P4……Pn。所以记住，在职责扩散到我们无法控制的程度之前，立刻对代码进行重构。）

【原则】

只有逻辑足够简单，才可以在代码级别上违反单一职责原则；只有类中方法数量足够少，才可以在方法级别上违反单一职责原则；

【优点】

可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；

提高类的可读性，提高系统的可维护性；

变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。

需要说明的一点是单一职责原则不只是面向对象编程思想所特有的，只要是模块化的程序设计，都适用单一职责原则。

【实际应用】

单一职责原则是软件设计中最简单的原则之一，也是最难正确运用的原则之一。人们会自然地把职责结合在一起。很多情况下软件设计真正要做的许多工作正式发现职责并把职责相互分离。下面就介绍一些单一职责原则的一些常见实践方法。

鉴别职责

每一个系统中的功能都表示了一个职责，这些职责可以映射到软件模块（类）中，且应该尽可能的保证这些模块之间没有功能上的重复。设计中每次应只关注一个职责。但这并不是说讲其他的职责都抛之脑后，而是说当决定用某个模块来实现某个职责之后，只需全神贯注与该职责就可以了。从这个模块的角度出发，其他的职责都是不相关的。

信息隐藏

模块（类）拥有自己公开的接口，可以和其他模块通信，同时模块也包含大量内部信息供自身使用。模块中只有接口暴露出的成员才能供其他模块使用。内部数据不是被彻底隐藏，就应被筛选后才能暴露给外部。这样，每个模块仍可以使用固定的接口来通信，而同时不会受到修改具体实现的影响。

持久化

将持久、稳定的数据功能和频频变化的业务规则分离。这样持久化的方式就不会因业务层的变化而频繁变化了。最常见应用此思想的就是三层架构和MVC架构。

【相关知识】

单一职责原则并不是一个孤立的面向对象设计原则，它是面向对象设计五个基本原则（SOLID）之一。这些原则是：单一职责原则、开闭原则、里氏替换原则和依赖倒置原则。这些原则被一起应用时可以使一个软件系统更易被维护和扩展。这些原则被典型的应用在测试驱动开发上，并且是敏捷开发以及自适应软件开发等指导思想的重要组成部分。

【发展历史】

单一职责原则是面向对象五个基本原则（SOLID）中的S。但他并不限于编程语言、设计方法，甚至超越了纯粹的编程领域，还应用到了软件架构的很多方面。而且其发展自1974年艾兹格・W・迪科斯彻（EdsgerWybeDijkstra）在论文《In the Role of ScientificThought》提出的分离关注点原则和汤姆・狄马克(TomDeMarco)在论文《Structed Analsis andSystem Specification》中提出的内聚性原则。然而这两个原则最初并不应用于面向对象设计，而是支持过程式编程（Procedural Programming）的理念。在过程式编程中，单一职责原则是依赖函数和过程实现的。

随着面向对象编程（OOP）语言的出现，人们才开始用类来分离关注点。从而被罗伯特・C・马丁（RobertC.Martin）总结出了单一职责原则。

【发明人简介】

罗伯特・C・马丁（RobertC.Martin）业内人称Bob大叔，世界级软件开发大师，著名软件公司Object Mentor公司的创始人和总裁。曾担任C++ Report杂志主编多年，也是设计模式和敏捷开发运动的主要倡导者之一。