设计原则之单一职责原则

定义:一个类只负责一项职责,应该只有一个能引起它变化的原因。

问题:类T负责两个不同的职责:职责P1,职责P2。当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常     的职责P2功能发生故障。

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

举个栗子:介绍几种动物的栖息地和食物,这里边有两项职责:栖息地和食物。

用一个类Recommend介绍牛生活在陆地上,吃的是青草;羊生活在陆地上,吃的是青草。

运行后的结果是:

以上,类Recommend负责两个不同的职责:职责P1(动物),职责P2(栖息地),当职责P1发生改变,比如增加一个动物猪的时候,猪吃的不是青草,那么我们就需要修改类Recommend,修改的方式有两种:

一是将类Recommend分解成类Recommend01和类Recommend02,如下:

然后在SRPFragment中分别调用:

运行后的结果是:

可以看出,将原来的类Recommend进行分解的做法,不仅修改的花销很大,还需要修改SRPFragment中的代码,所以不推荐。我们能不能直接修改类Recommend呢?二是在类Recommend的rede方法中加个判断,来区分吃青草的牛羊和吃五谷杂粮的猪:

运行后的结果是同上。如此修改要简单得多,但当我们再加一种动物鱼的时候,又要去修改类Recommend中的rede方法,假设rede方法很复杂,那么就会对原有的方法带来风险。所以我们就要用到单一职责原则来解决这个问题,在类Recommend中添加一个新的方法用于介绍鱼的栖息地和食物,这样不会影响到之前的功能了,如下:

运行后的效果是:

可以看到,这种修改方式没有去改动原来的方法,所以不会影响到原有功能的使用,在方法级别上是符合单一职责原则的。
原则:如果一个类承担的职责越多,那么它被复用的可能性就越小,并且一个类承担的职责过多的话,这些职责就会耦合在一起,     当其中一个职责发生改变时,就可能会影响到其他职责的运作,这样的话势必会影响到后期功能的优化或扩展。     将这些职责进行适当地分离,将不同的职责封装到不同的类中,注意的是对于那些总是同时发生改变的多个职责,可将     它们封装在同一类中。

优点:高内聚,低耦合。可降低类的复杂度,提高类的可读性,提高系统的可维护性,在一定程度上降低变更引起的风险。
				
时间: 2024-10-22 16:54:24

设计原则之单一职责原则的相关文章

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

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

面向对象设计原则:单一职责原则(The Single Responsibility Principle)

热爱生活.享受娱乐.专注技术,欢迎关注微信公众号QGer,我们一起见证成长! 什么是单一职责原则? - 官方解释:一个类应该只有一种改变的原因 - 通俗解释:一个类被修改.拓展的时候,应该只能因为一种职责(功能)的扩展,而不应该有第二种职责导致类的修改,一个也不能有另一种职责存在. 为什么遵循单一职责原则? 降低类的复杂度,一个类负责一种职责,逻辑上也变得直观简单. 使代码变得灵活,提高系统的维护性. 变更的风险降低,有需求就会有变更,单一职责原则可降低变更的影响面. 保持松耦合,提供内聚. 如

[敏捷设计]2.SRC单一职责原则

一.定义 一个类应该只有一个发生变化的原因. 二.为什么要使用SRC 因为每一个职责都是变化的一个轴线.当需求变化时,这种变化就会反映为类的职责的变化.如果一个类承担了多于一个的职责,那么引起它变化的原因就会有多个. 如果一个类承担的职责过多,就等于把这些职责耦合在了一起.一个职责的变化可能会消弱或抑制这个类完成其他职责的能力.这种耦合会导致脆弱的设计,当变化发生时,设计会遭到意想不到的破坏. 三.案例演示 考虑图中的设计. Rectangle类具有两个方法,一个方法把矩形绘制到屏幕上,另一个方

6大设计原则(1):单一职责原则

定义:应该且仅有一个原因引起类的变更. 理解: 如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力, 这种耦合会导致脆弱的设计.当变化发生时,设计会遭受到意想不到的破坏. 假如一个类A,有两个职责a,b,当职责a由于需求发生变化而需要修改时,有可能会导致职责b的功能发生故障. 解决: 将类中的职责分开,分别建立两个类. 如果是面向接口编程的话,就是将两个职责抽象成为两个不同的接口,原接口再实现这两个接口. 单一职责原则的好处: 1.类的

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

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

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

单一职责原则是最简单的面向对象设计原则,它用于控制类的粒度大小.单一职责原则定义如下: 单一职责原则(Single Responsibility Principle, SRP):一个类只负责一个功能领域中的相应职责,或者可以定义为:就一个类而言,应该只有一个引起它变化的原因. 单一职责原则告诉我们:一个类不能太“累”!在软件系统中,一个类(大到模块,小到方法)承担的职责越多,它被复用的可能性就越小,而且一个类承担的职责过多,就相当于将这些职责耦合在一起,当其中一个职责变化时,可能会影响其他职责的

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

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

6大设计原则之单一职责原则

单一职责原则 如果有一个用户管理类,类图如下 我想,任谁也能看的出这个接口设计的有问题,用户的属性和用户的行为没有分开,应该把用户的信息抽取成一个业务对象,把用户的行为抽取成一个业务对象,按照这个思路对类图进行修正,如下图所示 其实,在实际使用中我们更倾向于使用两个不同的接口: 一个IUserBO,一个IUserBiz 单一职责原则定义 应该有且仅有一个原因引起类的变更 单一职责原则的好处: 类的复杂性降低,实现什么职责都有清晰明确的定义 可读性提高,复杂性降低了,可读性当然就提高了 可维护性提

面向对象五大原则_1.单一职责原则&2.里氏替换原则

单一职责原则:Single Responsibility Principle (SRP) 一个类.仅仅有一个引起它变化的原因.应该仅仅有一个职责.每个职责都是变化的一个轴线.假设一个类有一个以上的职责,这些职责就耦合在了一起.这会导致脆弱的设计.当一个职责发生变化时,可能会影响其他的职责.另外,多个职责耦合在一起,会影响复用性. 比如:要实现逻辑和界面的分离. T负责两个不同的职责:职责P1.职责P2.当因为职责P1需求发生改变而须要改动类T时.有可能会导致原本执行正常的职责P2功能发生问题.