第三章 单一职责原则

定义

单一职责原则(Single Responsibility Principle,SRP)又称单一功能原则,由罗伯特·C.马丁(Robert C. Martin)于《敏捷软件开发:原则、模式和实践》一书中提出的。这里的职责是指类变化的原因,单一职责原则规定一个类应该有且仅有一个引起它变化的原因,否则类应该被拆分(There should never be more than one reason for a class to change)。

该原则提出对象不应该承担太多职责,如果一个对象承担了太多的职责,至少存在以下两个缺点:

  1. 一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力;
  2. 当客户端需要该对象的某一个职责时,不得不将其他不需要的职责全都包含进来,从而造成冗余代码或代码的浪费。

    单一职责原则的优点

    单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。如果遵循单一职责原则将有以下优点:

  3. 降低类的复杂度。一个类只负责一项职责,其逻辑肯定要比负责多项职责简单得多。 提高类的可读性。复杂性降低,自然其可读性会提高。
  4. 提高系统的可维护性。可读性提高,那自然更容易维护了。
  5. 变更引起的风险降低。变更是必然的,如果单一职责原则遵守得好,当修改一个功能时,可以显著降低对其他功能的影响。

    单一职责原则的实现方法

    单一职责原则是最简单但又最难运用的原则,需要设计人员发现类的不同职责并将其分离,再封装到不同的类或模块中。而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。下面以大学学生工作管理程序为例介绍单一职责原则的应用。

原文地址:https://www.cnblogs.com/liuxiany/p/12643826.html

时间: 2024-10-11 03:02:59

第三章 单一职责原则的相关文章

第3章 单一职责原则

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

第三话-单一职责原则

 写在前面:本人最近在看<大话设计模式>这本书,书里是用C#讲解的实例.现在写心得笔记与大家分享,就试着写一个JAVA版的.例子还是书里的例子.不过是Java语言实现的.后面也会给出本人的一些理解建议.谢谢<大话设计模式>的作者. 一.什么是单一职责原则? 今天要说的是单一职责原则,这个应该比较好理解.所谓单一职责,就一个类而言,应该仅有一个引起它变化的原因.也就是说它只做简单的一件事,只是做好自己的本质工作其他尽量不去参与. 在我们设计类的时候,我们往往还没有好好思考就开始编

三、单一职责原则、开放-封闭原则、依赖倒转原则

一.单一职责原则 1.定义:就一个类而言,应该仅有一个引起它变化的原因. 2.为什么要?:如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力.这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏. 3.软件设计真正要做的许多内容,就是发现职责并把职责相互分离. 如果你能想到多余一个动机去改变一个类,那么这个类就具有多于一个原则. 4.示例:设计俄罗斯方块的游戏 可以分为游戏逻辑和界面表示逻辑. 游戏逻辑--数组每一项的值改

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

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

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

鲍勃大叔说: 单一职责原则(SRP):就一个类而言,应该仅有一个引起它变化的原因. 我最开始理解成只能有一个原因去改变,跟我以前的认知有问题,从我开始学OOP以来,我觉得一个类就是一个事物的抽象,比如书,BOOK类,如果按照我理解的意思,book类就有很多可以改变它的原因,例如翻书或者买书,我感觉SRP说的是函数的职责,不是类的职责,于是我就去找了一个同学讨论,然后我们讨论了一会,得出的结论是这样的(以保龄球为例): SRP指的是只改变保龄球相关的内容算一件事,如果我用一个比赛类去代替保龄球的话

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

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

第 3 章 单一职责原则

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

大话设计模式第三章之单一职责原则

单一职责原则指的是就一个类而言,应该仅有一个引起它变化的原因. 如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能削弱或者抑制这个类完成其它职责的能力(就像一个程序员  叫他去做医学研究,生物研究,可能会抑制他学设计模式的能力).这种耦合会导致脆弱的设计,当变化发生时,设计会遭到异常不到的破坏(你医学研究久了,设计模式少接触,也就生疏了). 在写一个类的时候,要在类的职责分离上多思考(类的职责搞不清楚,就好像你生病了去找修车的,买菜去学校买),这样代码才是真正的可维护,易扩

设计模式(三)面向对象设计原则之单一职责原则

引用自:http://blog.csdn.net/lovelion  作者:刘伟 单一职责原则是最简单的面向对象设计原则,它用于控制类的粒度大小.单一职责原则定义如下: 单一职责原则(Single Responsibility Principle, SRP):一个类只负责一个功能领域中的相应职责, 或者可以定义为:就一个类而言,应该只有一个引起它变化的原因. 单一职责原则告诉我们:一个类不能太"累"!在软件系统中,一个类(大到模块,小到方法)承担的 职责越多,它被复用的可能性就越小,而