设计模式六大原则——单一职责原则(SRP)

定义

就一个类而言,应该仅有一个引起它变化的原因。通俗的说,一个类只负责一项职责。

问题的由来

手机的功能多,但是每一项的功能都不强:

拍摄功能——>专业的摄像机和照相机

手机游戏——>PSP

网络摄像头——>专业摄像头

GPS功能——>专业GPS导航系统

每一个职责都是一个变化的轴线,当需求变化时会反映为类的职责的变化,如果一个类的承担的职责多于一个,那么引起她变化的原因就有多个,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力,从而导致脆弱的设计。

解决方案

遵循单一职责原则。分别建立两个类T1、T2,使T1完成职责P1功能,T2完成职责P2功能。这样,当修改类T1时,不会使职责P2发生故障风险;同理,当修改T2时,也不会使职责P1发生故障风险。

示例

 public interface Program
    {
        void draw();     //绘制图形
        void area();     //计算面积
    }

    public class DrawGraph implements Program
    {
        public void draw()
        {
            System .Out.PrintIn("绘制图形");
        }
        public void area(){}
    }
    public class AreaCount implements Program
    {
        public void draw(){}
        public void area()
        {
            System .out.printIn("计算面积");
        }
    }

}

以上 图形计算程序只使用了正方形的Area()方法,永远不会使用Draw()方法,而它却跟Draw方法关联了起来。这违反了单一原则,如果未来因为图形绘制程序导致Draw()方法产生了变化,那么就会影响到本来毫不关系的图形计算程序。

应该把接口改成2个,将不同的职责分配给不同的类,使单个类的职责尽量单一,就隔离了变化,这样他们也不会互相影响了。

public interface Draw
    {
        void draw();     //绘制图形
    }

    public interface Area
    {
        void area();    //计算面积
    }

然后分别实现接口,如下:

时间: 2024-08-01 00:33:36

设计模式六大原则——单一职责原则(SRP)的相关文章

设计模式--6大原则--单一职责原则

单一职责原则(Single Responsibility Principle),简称SRP. 定义: There should never be more than one reason for a class to change. 应该有且仅有一个原因引起类的变更. 有时候,开发人员设计接口的时候会有些问题,比如用户的属性和用户的行为被放在一个接口中声明.这就造成了业务对象和业务逻辑被放在了一起,这样就造成了这个接口有两种职责,接口职责不明确,按照SRP的定义就违背了接口的单一职责原则了. 下

Android与设计模式:用单一职责原则为Activity解耦

一.什么是单一职责原则 单一职责原则(SRP:Single responsibility principle)又称单一功能原则,其定义为:一个类,应该只有一个可以导致变化的原因.光看概念会让人很头疼,我先讲点小例子吧: 二.单一职责原则能解决什么问题 回顾我们的 Android 开发经历,很多人都会发现 Activity 类中的代码总会不知不觉地变得很多,这会让读我们代码的人非常痛苦.而造成这种情况的其中一个原因是:Activity 中需要与用户进行大量的交互,用户的操作会改变 Activity

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

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

设计模式六大原则: 单一职责原则

定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责.  问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案:遵循单一职责原则.分别建立两个类T1.T2,使T1完成职责P1功能,T2完成职责P2功能.这样,当修改类T1时,不会使职责P2发生故障风险:同理,当修改T2时,也不会使职责P1发生故障风险. 说到单一职责原则,很多人都会不屑一顾.因为它太简单了.稍有经验的程序员即

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

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

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

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

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

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

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

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

设计模式六大原则(1)--单一职责原则

定义: 一个类,只有一个引起它变化的原因.通俗的来说就是一个类只负责一项职责. 问题由来: 类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案: 遵循单一职责原则,设计两个类T1和T2,T1负责完成职责P1,T2负责完成P2.当P1变动需要修改T1时不会影响T2:同理,当P2变动需要修改T2时不会影响T1.这样,T1与T2之间职责不同,独立存在,因此无论修改哪一项的实现功能都不会影响另一方的职责. 说