五大设计原则之(二)---单一职责原则

单一职责原则(SRP:Single responsibility principle)又称单一功能原则,它规定一个类应该只有一个发生变化的原因。

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

单一职责的好处:

1.类的复杂性,实现什么职责都有清晰明确的定义

2。可读性提高,复杂性,那当然可读性提高了

3. 可性提高,可读性提高,那当然容易维护了。

4.变更引起的风险降低,变更是必不可少的,如果接口的单一职责做得好,一个接口修改只对相应的实现类有影响,对其他的接口无影响,这对扩展性、维护性都有非常大的帮助。

时间: 2024-08-11 09:49:57

五大设计原则之(二)---单一职责原则的相关文章

设计模式学习笔记(二) 设计基本原则之【单一职责原则】

单一职责原则(SRP: Single Responsibility Principle) 名词解释: 1) 职责:是指类变化的原因. 2) 职责扩散:就是因为某种原因,职责P被分化为粒度更细的职责P1和P2. 3) 可变类:是指创建该类的实例后,可以对其属性进行修改. 4)不可变类:是指创建该类的实例后,不可对其属性进行修改.不可变类是线程安全的. 1.应用场景 一个类T负责两个不同的职责:职责P1.职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原来运行的职责P2功能发生故障

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

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

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

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

[转]设计模式六大原则[1]:单一职责原则

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

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

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

面向对象设计原则一:单一职责原则(SRP)

单一职责原则(SRP) 定义:系统中的每一个类都应该只有一个职责. 好处:高内聚.低耦合. 解释说明: 单一职责也就是说我们应该让一个类或一个对象只做一件事情,每个类所要关注的就是自己要完成的职责是什么,能够引起这个类变化的原因也应该只有一个,这也是后面提到的所有的设计模式都会遵守的一个原则. 高内聚:先按照面向对象的封装特性来理解,封装也就是我们说的,应该把一个类或对象它所有相关的属性.方法.行为放到一起,放到一个类中,这样就实现了一个封装的特性.那么内聚,就是一个类里面应该包含它所有的属性和

面向对象设计原则之单一职责原则(SRP)

Web程序猿博客:http://blog.csdn.net/thinkercode 这条原则曾经在 Tom DeMaro 和 Meilir Page-Jones 的著作中描述过,并称之为内聚性(cohesion).他们把内聚性定义为:一个模块的组成元素之间的功能相关性. 单一职责原则(SRP) 单一职责原则(Single Responsibility Principle, SRP):就一个类而言,应该仅有一个引起它变化的原因. 单一职责的原则告诉我们:在软件系统中,如果一个类承担的职责过多,就等

单一职责原则详解--七大面向对象设计原则(1)

单一职责原则来源: 定义:单一职责就是一个类负责一项职责.就一个类而言,应该只专注于做一件事和仅有一个引起它变化的原因. 所谓职责,我们可以理解为功能,就是设计的这个类功能应该只有一个,而不是两个或更多.也可以理解为引用变化的原因,当你发现有两个变化会要求我们修改这个类,那么你就要考虑撤分这个类了.因为职责是变化的一个轴线,当需求变化时,该变化会反映类的职责的变化. 单一职责原则,很太简单.大多数开发人员,在设计软件时也会自觉的遵守这一重要原则,因为这是常识.在软件编程中,谁也不希望因为修改了一

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

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