DH03-单一职责原则

模式简介

就一个类而言,应该仅有一个引起它变化的原因。不要存在多于一个导致类变更的原因。遵循单一职责原则。分别建立两个类T1和T2,使T1完成P1功能,T2完成P2功能。当修改T1时,不会使职责P2发生故障风险。

遵循单一职责原的优点有:

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

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

类图分析

程序代码

#include <iostream>
#include <string>
using namespace std;

class Reptilian
{
public:
    void run(string reptilian)
    {
        cout<< reptilian << " can run" << endl;
    }
};
class Bird
{
public:
    void fly(string bird)
    {
        cout <<bird<< " can fly" << endl;
    }
};

int main()
{
    Reptilian reptilian;
    reptilian.run("dog");
    reptilian.run("cat");

    Bird bird;
    bird.fly("eagle");
    bird.fly("sparrow");
    system("pause");
    return 0;
}

参考资料

设计模式六大原则:http://www.uml.org.cn/sjms/201211023.asp

设计模式6大原则之-单一职责原则:http://blog.csdn.net/yuluows/article/details/7013343

时间: 2024-08-02 17:20:32

DH03-单一职责原则的相关文章

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

单一职责原则(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

设计模式.设计原则-单一职责原则

1:什么情况下 会使用到单一职责原则设计模式? 当同一个类中同时出现业务和属性等代码的时候或者当同一个类中要做多样事情的时候,就需要将其抽象出来,做成多种不同的接口,以便后续方便扩展单一职责:原则要求一个接口或者类只有一个原因引起变化,也就是一个接口或者类只有一个职责,它就负责一件事情 单一原则的好处:类的复杂性降低,实现责任清晰明确可读性高,复杂性降低可维护性提高,可读性提高变更引起风险性降低,变更是必不可少的,如果接口修改,只影响对应的实现类,对其他接口没有影响 如上图所示:Perion类这

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

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

设计模式之禅单一职责原则

个人blog 此篇博文地址 :http://www.sanyinchenblog.com/?p=150 最近在看<<设计模式之禅>>感觉这本书很是不错的,demo虽然简单但是确实很明了,感觉很有必要自己再敲一遍 单一职责原则 demo: https://github.com/sanyinchen/UMLDemo 如果一个类有多于一个的动机被改变,那么这个类就具有多于一个的职责.而单一职责原则就是指一个类或者模块应该有且只有一个改变的原因. demo:一个手机类:Iphone.需要用

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

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

单一职责原则

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

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

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

Java设计原则—单一职责原则(转)

定义: 应该有且仅有一个原因引起类的变更. There should never be more than one reason for a class to change. 优点: 1.类的复杂性降低,实现什么职责都有清晰明确的定义: 2.可读性提高,复杂性减低,可读性当然提高: 3.可维护性提高,可读性提高,可维护性当然提高: 4.变更引起的风险减低,变更是必不可少的,如果接口的单一职责做得好,一个接口修改只对相应的类有影响,对其他接口无影响,这对系统的扩展性.维护性都有非常大的帮助. 注意