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

单一职责原则(SRP)

定义:系统中的每一个类都应该只有一个职责。

好处:高内聚、低耦合。

解释说明:

单一职责也就是说我们应该让一个类或一个对象只做一件事情,每个类所要关注的就是自己要完成的职责是什么,能够引起这个类变化的原因也应该只有一个,这也是后面提到的所有的设计模式都会遵守的一个原则。

高内聚:先按照面向对象的封装特性来理解,封装也就是我们说的,应该把一个类或对象它所有相关的属性、方法、行为放到一起,放到一个类中,这样就实现了一个封装的特性。那么内聚,就是一个类里面应该包含它所有的属性和行为。封装就是内聚的一种表现方式。高内聚是指我们一个类的属性和行为应该和这个类非常紧密,我们才把它放到这个类里面,反之我们就不应该把这个属性或行为放到这个类里面。

低耦合:内聚是指类的内部,耦合是指类与类之间或者模块之间相互的联系,这种联系、关系叫耦合,衡量这种耦合的程度,可以用耦合度来表示,耦合度越高说明类与类之间的联系是越紧密的,也就是相互之间的独立性比较差,也就是一个类必须依靠另外一个类才有意义,才能存在。耦合度越低,越容易重用,类也比较灵活。

错误案例1:

 1 using System;
 2 using System.Collections.Generic;
 3 using System.Linq;
 4 using System.Text;
 5 using System.Threading.Tasks;
 6
 7 namespace 单一职责_SRP_
 8 {
 9     /// <summary>
10     /// 会计类
11     /// </summary>
12     public class Accountant
13     {
14         /// <summary>
15         /// 计算工资
16         /// </summary>
17         public void CalculateSalary()
18         {
19            // 计算工资
20         }
21
22         /// <summary>
23         /// 存储数据
24         /// </summary>
25         public void Store()
26         {
27            // 存储数据
28         }
29     }
30 }

在上面的代码中定义了一个会计类,类里面有两个方法:计算工资和存储数据。一个类里面有两个职责,并且引起这个类变化的原因有很多种:一个是计算工资的方法的参数的变化会影响类的变化,存储数据的方法的变化也会影响类的变化,没有很好的实现单一职责原则,应该把计算工资和存储数据分开。

错误案例2:

 1 using System;
 2 using System.Collections.Generic;
 3 using System.Linq;
 4 using System.Text;
 5 using System.Threading.Tasks;
 6 using System.Data.SqlClient;
 7 using System.Data;
 8
 9 namespace 单一职责_SRP_
10 {
11     public interface IDao
12     {
13         // 获取数据库连接
14         SqlConnection GetConnection();
15         // 关闭连接
16         void Close();
17         // 执行添加、更新、删除操作
18         void ExecuteUpdate(string strSQL);
19         // 执行查询操作
20         DataSet ExecuteQuery(String strSQL);
21     }
22 }

上面的代码中定义了一个数据访问类,里面有两个方法:数据链接、执行增删改查的操作。数据链接一般和配置文件关联比较大。如果配置文件没有配置好、或者数据库服务没有开启,那么数据库链接可能就打不开。执行增删改查主要和SQL语句有关系。最理想的设计应该是把与数据链接有关的操作封装成一个类,把执行增删改查的操作封装到另外一个类中。

在上面的两个错误案例中,一个类都实现了两个职责,而不是一个职责,不符合单一职责的原则。这样设计类不是最完美的,建议按照单一职责的原则细分成两个类,这样就能实现高内聚低耦合。

时间: 2024-10-14 09:56:24

面向对象设计原则一:单一职责原则(SRP)的相关文章

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

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

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

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

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

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

面向对象设计原则之单一职责原则(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):一个类只负责一个功能领域中的相应职责, 或者可以定义为:就一个类而言,应该只有一个引起它变化的原因. 单一职责原则告诉我们:一个类不能太"累"!在软件系统中,一个类(大到模块,小到方法)承担的 职责越多,它被复用的可能性就越小,而

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

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

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

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

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

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

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

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