(1)Single Responsibility Principle【单一职责原则】

单一职责原则

SRP:Single responsibility principle

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

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

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

【原理】

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

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

【产生原因】

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

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

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

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

比如:类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杂志主编多年,也是设计模式和敏捷开发运动的主要倡导者之一。

时间: 2024-11-05 11:53:19

(1)Single Responsibility Principle【单一职责原则】的相关文章

面向对象编程6大设计原则:单一职责原则

单一职责原则(Single  Responsibility Principle)简称SRP原则. 定义 应该有且仅有一个原因引起类的变更. 优点 可以降低类的复杂度,一个类只负责一项职责,其逻辑肯定要比负责多项职责简单的多: 提高类的可读性,提高系统的可维护性: 变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响. 说明 单一职责原则不只是面向对象编程思想所特有的,只要是模块化的程序设计,都适用单一职责原则: 单一职责原则要根据项目的实际情

C#设计模式系列:单一职责原则(Single Responsibility Principle)

1.单一职责原则的核心思想 一个类应该有且只有一个变化的原因. 2.为什么要引入单一职责原则 单一职责原则将不同的职责分离到单独的类,每一个职责都是一个变化的中心.当需求变化时,这个变化将通过更改职责相关的类来体现.如果一个类拥有多于一个的职责,则这些职责就耦合到在了一起,那么就会有多于一个原因来导致这个类的变化.对于某一职责的更改可能会损害类满足其他耦合职责的能力.这样职责的耦合会导致设计的脆弱,以至于当职责发生更改时产生无法预期的破坏. 3.单一职责原则的优点 1>.可以降低类的复杂度,一个

设计模式 之 单一职责原则 (Single Responsibility Principle)

Motivation 动机 In this context, a responsibility is considered to be one reason to change. This principle states that if we have 2 reasons to change for a class, we have to split the functionality in two classes. Each class will handle only one respon

单一职责原则(Single Responsibility Principle SRP)

对于单一职责原则,其核心思想为: 一个类,最好只做一件事,只有一个引起它的变化. 单一职责原则可以看做是低耦合.高内聚在面向对象原则上的引申,将职责定义为引起变化的原因,以提高内聚性来减少引起变化的原因. 职责过多,可能引起它变化的原因就越多,这将导致职责依赖,相互之间就产生影响,从而大大损伤其内聚性和耦合度. 通常意义下的单一职责,就是指只有一种单一功能,不要为类实现过多的功能点,以保证实体只有一个引起它变化的原因.

六大设计原则——单一职责原则【Single Responsibility Principle】

声明:本文内容是从网络书籍整理而来,并非原创. 用户管理的例子 先看一张用户管理的类图: 再看一眼上面的图,思考:这样合理吗? 这个接口是一个很糟糕的设计! 用户的属性和行为竟然混合在一起!!! 正确的做法是把用户的信息抽取成一个业务对象(Bussiness Object,简称 BO),把行为抽取成另外一个接口中,我们把这个类图重新画一下: 这样划分成了两个接口,IUserBO 负责用户的属性,IUserBiz 负责用户的行为,因为是面向的接口编程,所有当产生了这个 UserInfo 对象之后,

面向对象设计原则:单一职责原则(The Single Responsibility Principle)

热爱生活.享受娱乐.专注技术,欢迎关注微信公众号QGer,我们一起见证成长! 什么是单一职责原则? - 官方解释:一个类应该只有一种改变的原因 - 通俗解释:一个类被修改.拓展的时候,应该只能因为一种职责(功能)的扩展,而不应该有第二种职责导致类的修改,一个也不能有另一种职责存在. 为什么遵循单一职责原则? 降低类的复杂度,一个类负责一种职责,逻辑上也变得直观简单. 使代码变得灵活,提高系统的维护性. 变更的风险降低,有需求就会有变更,单一职责原则可降低变更的影响面. 保持松耦合,提供内聚. 如

面向对象设计原则之一:单一职责原则

单一职责原则(Single Responsibility Principle SRP) There should never be more than one reason for a class to change. 什么意思呢? 所谓单一职责原则就是一个类只负责一个职责,只有一个引起变化的原因. 如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化会削弱或抑制这个类完成其他职责的能力,这个耦合会脆弱的设计. 软件设计真正要做的许多内容,就是发现职责并把这些职责相互分离:如果能

【设计模式之禅】第1章 单一职责原则

1.1 我是"牛"类,我可以担任多职吗 SRP 单一职责原则的英文名称是Single Responsibility Principle,简称是SRP. RBAC模型(Role-Based Access Control)基于角色的访问控制        通过分配和取消角色来完成用户权限的授予和取消,使动作主体(用户)与资源的行为(权限)分离 单一职责原则的定义是:应该有且仅有一个原因引起类的变更. 1.2 绝杀技,打破你的传统思维 SRP的原话解释是:        There shou

单一职责原则

什么是单一职责原则 什么是单一职责原则? 单一职责原则的英文名称是Single Responsibility Principle,简称SRP.SRP的原话解释是:There should never be more than one reason for a class to change. 也就是说一个类,只有一个引起它变化的原因.应该只有一个职责.每一个职责都是变化的一个轴线,如果一个类有一个以上的职责,这些职责就耦合在了一起. 这会导致脆弱的设计.当一个职责发生变化时,可能会影响其它的职责