敏捷开发:原则,模式与实践——第8章 单一职责原则SRP

鲍勃大叔说:

单一职责原则(SRP):就一个类而言,应该仅有一个引起它变化的原因。

我最开始理解成只能有一个原因去改变,跟我以前的认知有问题,从我开始学OOP以来,我觉得一个类就是一个事物的抽象,比如书,BOOK类,如果按照我理解的意思,book类就有很多可以改变它的原因,例如翻书或者买书,我感觉SRP说的是函数的职责,不是类的职责,于是我就去找了一个同学讨论,然后我们讨论了一会,得出的结论是这样的(以保龄球为例):

SRP指的是只改变保龄球相关的内容算一件事,如果我用一个比赛类去代替保龄球的话,那就违背了SRP,因为可能会有羽毛球类,然后就会有多个原因让比赛类改变了,大概理解是这样的。

时间: 2024-08-26 09:47:22

敏捷开发:原则,模式与实践——第8章 单一职责原则SRP的相关文章

第3章 单一职责原则

单一职责原则(SRP),就一个类而言,应该仅有一个引起它变化的原因. 如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能削弱或者抑制这个类完成其他职责的能力.这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏. 软件设计真正要做的许多内容,就是发现职责并把哪些职责相互分离.如果你能够像到多于一个的动机去改变一个类,那么这个类就多于一个的职责,就应该考虑类的职责分离. 比如俄罗斯方块游戏,在移动端移植到PC端,可以将界面类和逻辑类分离,达到复用的目的. 第3章

第三章 单一职责原则

定义 单一职责原则(Single Responsibility Principle,SRP)又称单一功能原则,由罗伯特·C.马丁(Robert C. Martin)于<敏捷软件开发:原则.模式和实践>一书中提出的.这里的职责是指类变化的原因,单一职责原则规定一个类应该有且仅有一个引起它变化的原因,否则类应该被拆分(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

[Python设计模式] 第3~5章 单一职责原则/开放-封闭原则/依赖倒转原则

单一职责原则 就一个类而言,应该仅有一个引起它变化的原因. 如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力.这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏. 软件设计真正要做的许多内容,就是发现职责并把哪些职责相互分离.如果你能够想到多余一个的动机去改变一个类,那么这个类就具有多余一个的职责,就应该考虑类的职责分离. 开放-封闭原则 开放-封闭原则,是说软件实体(类,模块,函数等)应该可以扩展,但是不可修改.即对

第 3 章 单一职责原则

就一个类而言,应该仅有一个引起它变化的原因.   如果一个类承担的职责过多,就等于把这些职责耦合在一起,   一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力.   这种耦合会导致脆弱的设计,当变化产生时,设计会遭受到意向不到的破坏.   软件设计真正要做的许多内容,就是发现职责并把那些职责相互分离.

面向对象五大原则之一:单一职责原则(自我理解)

http://www.cnblogs.com/seacryfly/archive/2011/12/29/2305965.html 只有类对应的(唯一)职责(需求)的变更才会引起代码的重构. The single responsibility principle states that every module or class should have responsibility over a single part of the functionality provided by the so

敏捷开发-原则 模式与实践(1)

敏捷开发-原则 模式与实践 这的确是一本关于开发者的好书,对于我们开发者.研究人员,它提出了一个开发的全新的价值观(对我来说),甚至人生都有启发.需要认真阅读. 书中总结了敏捷开发的实例,确确实实更够感觉到对于项目的完成大有裨益,有种相读恨晚的感觉.想想自己之前的开发状态,想想自己导师安排公司项目的情况,就是低效率,就是小儿科,就是书上批评讽刺的那样,这正是开发者十几年开发智慧的结晶,前人的经验,前人的智慧,激发了我的阅读的快感,我获取知识的兴奋感,激发了我的成就感. 阅读前两天(结合思维导图)

敏捷软件开发 – SRP 单一职责原则

SRP:单一职责原则  一个类应该只有一个发生变化的原因. 为何把两个职责分离到单独的类中很重要呢?因为每一个职责都有变化的一个轴线.当需求变化时,该变化会反映为类的职责的变化.如果一个类承担了多于一个的职责,那么引起它变化的原因就会有多个. 如果一个类承担的职责过多,就等于把这些职责耦合在了一起.一个职责发生变化可能会削弱或抑制这个类完成其他职责的能力.这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏. 有两个不同的应用程序使用Rectangle类.一个应用程序是有关计算几何

敏捷软件开发——单一职责原则(SRP)

定义: 简单来说,单一职责原则(SRP)就是对对一个类而言,应该仅有一个引起它变化的原因. 什么是职责? 在SRP中,职责 =  a reason for change .如果你能想到多于一个的动机去改变一个类,那么这个类就具有多于一个职责. 具体的例子可以看敏捷软件开发 p91 . SRP是所有原则找那个最简单的之一,也是最难正确运用的之一.我们会自然地把职责结合在一起.软件设计真正要做的许多内容,就是发现职责并把那些职责相互分离. 不好意思,写的有点简单了?,刚刚看到这部分,后面会有具体的例