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

单一职责原则（SRP）

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

好处：高内聚、低耦合。

解释说明：

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

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

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

错误案例1：

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace 单一职责_SRP_
{
    /// <summary>
    /// 会计类
    /// </summary>
    public class Accountant
    {
        /// <summary>
        /// 计算工资
        /// </summary>
        public void CalculateSalary()
        {
           // 计算工资
        }

        /// <summary>
        /// 存储数据
        /// </summary>
        public void Store()
        {
           // 存储数据
        }
    }
}

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

错误案例2：

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Data.SqlClient;
using System.Data;

namespace 单一职责_SRP_
{
    public interface IDao
    {
        // 获取数据库连接
        SqlConnection GetConnection();
        // 关闭连接
        void Close();
        // 执行添加、更新、删除操作
        void ExecuteUpdate(string strSQL);
        // 执行查询操作
        DataSet ExecuteQuery(String strSQL);
    }
}

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

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

代码下载链接：点此下载

到此这篇关于C#面向对象设计单一职责原则的文章就介绍到这了。希望对大家的学习有所帮助，也希望大家多多支持我们。

赞 (0)

相关推荐

  • C#实现六大设计原则之里氏替换原则

    定义: 1:如果对每一个类型为 T1的对象 o1,都有类型为 T2 的对象o2,使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时,程序 P 的行为没有发生变化,那么类型 T2 是类型 T1 的子型. 2:所有引用基类的地方必须能透明地使用其子类的对象. 问题由来: 有一功能P1,由类A完成.现需要将功能P1进行扩展,扩展后的功能为P,其中P由原有功能P1与新功能P2组成. 新功能P由类A的子类B来完成,则子类B在完成新功能P2的同时,有可能会导致原有功能P1发生故障. 解决

  • C#面向对象设计原则之组合/聚合复用原则

    组合/聚合复用原则(LSP) 定义:优先使用组合,使系统更灵活,其次才考虑继承,达到复用的目的.重用的方式:继承.组合.聚合解释说明: 继承:在我们想复用代码时,我们一般会优先想到继承,但是具有继承关系的两个类是耦合度最高的两个类.(父类改了子类可能会受影响,子类改了父类也可能会受影响)如果父类的功能比较稳定,建议使用继承来实现代码复用,因为继承是静态定义的,在运行时无法动态调用. 组合:是整体与部分的关系,整体离不开部分,部分离开了整体没有意义,如飞机翅膀与飞机的关系. 聚合:也是整体与部分的

  • 浅谈C#六大设计原则

    笔者作为一个菜鸟,会尝试以简单的代码和容易理解的语句去解释这几种原则的特性和应用场景. 这六种原则分别为单一职责原则.接口隔离原则.里氏替换原则.迪米特法则.依赖倒置原则.开闭原则. 单一职责原则 单一职责原则(SRP:Single responsibility principle),规定一个类中应该只有一个原因引起类的变化. 单一职责原则的核心就是解耦和增强内聚性. 问题: // 假设此类是数据库上下文 public class DatabaseContext { } public class

  • C#实现六大设计原则之单一职责原则

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

  • C#面向对象设计原则之里氏替换原则

    里氏替换原则(LSP) 定义:在任何父类出现的地方都可以用它的子类类替换,且不影响功能.解释说明:其实LSP是对开闭原则的一个扩展,在OO思想中,我们知道对象是由一系列的状态和行为组成的,里氏替换原则说的就是在一个继承体系中,对象应该具有共同的外在特性,使用LSP时,如果想让我们的程序达到一个父类出现的地方都可以用它的子类来替换且不影响功能,那么这个父类也应该尽量声明出子类所需要的一些公共的方法,父类被子类替换之后,会比较顺利,那么为什么说它是对开闭原则的一个扩展呢?因为我们在开闭原则中说尽量使

  • C#实现六大设计原则之迪米特法则

    定义: 一个对象应该对其他对象保持最少的了解. 问题由来: 类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大. 解决方案: 尽量降低类与类之间的耦合. PS: 自从我们接触编程开始,就知道了软件编程的总的原则:低耦合,高内聚. 无论是面向过程编程还是面向对象编程,只有使各个模块之间的耦合尽量的低,才能提高代码的复用率. 低耦合的优点不言而喻,但是怎么样编程才能做到低耦合呢?那正是迪米特法则要去完成的. 迪米特法则又叫最少知道原则,最早是在1987年由美国Northe

  • C#面向对象设计原则之开闭原则

    开闭原则(OCP) 定义:对扩展开发,对修改关闭.好处: 适应性和灵活性. 稳定性和延续性. 可复用性与可维护性. 解释说明:开闭原则指的是两方面:对功能扩展开发,对修改进行关闭:有时当用户要求或需求发生变化时,我们不得不打开原来的代码进行修改,进行功能的扩展或增加,这种设计如果应用到我们以后的项目开发中会导致严重的问题,这样容易导致意外的错误.好的程序,应该保证在我们进行程序扩展时,不会更改以前的代码.如何才能保证这样的效果呢?我们在定义一个类的功能时:最好先定义他的抽象类或接口,这样在功能扩

  • C#实现六大设计原则之接口隔离原则

    C#实现六大设计原则之接口隔离原则

    接口隔离原则(ISP)定义: 客户端不应该依赖它不需要的接口:一个类对另一个类的依赖应该建立在最小的接口上. 问题由来: 类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现他们不需要的方法. 解决方案: 将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系.也就是采用接口隔离原则. 举例来说明接口隔离原则: 类A依赖接口I中的方法1.方法2.方法3,类B是对类A依赖的实现. 类C依赖接口I中的方法1.方法4.

  • C#面向对象设计原则之接口隔离原则

    接口隔离原则(ISP) 定义:使用多个专门的接口比使用单一的总接口要好.即不要把鸡蛋都放到一个篮子里.好处:比较灵活.方便,不想实现的或不用实现的可以不实现.解释说明:大部分人都喜欢用一个接口把需要用到的方法全部声明出来,但是ISP建议我们使用多个专门的接口比使用单一的总接口要好,也就是一个接口里的方法多的话,实现起来不是很方便. 示例1: using System; using System.Collections.Generic; using System.Linq; using Syste

  • C#实现六大设计原则之依赖倒置原则

    C#实现六大设计原则之依赖倒置原则

    依赖倒置原则(DIP)定义: 高层模块不应该依赖低层模块,二者都应该依赖其抽象:抽象不应该依赖细节:细节应该依赖抽象. 问题由来: 类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成.这种场景下,类A一般是高层模块, 负责复杂的业务逻辑:类B和类C是低层模块,负责基本的原子操作:假如修改类A,会给程序带来不必要的风险. 解决方案: 将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或者类C发生联系,则会大大降低修改类A的几率. ps: 依赖倒置原则

随机推荐