设计模式2.0——软件架构设计的七大原则——单一职责原则

本文介绍了单一职责原则,即一个 Class/Interface/Method 只负责一项职责。通过课程处理逻辑的代码示例,展示了如何对职责进行分离解耦,包括类、接口和方法层面。虽实际开发中很多类难符合该原则,但编写代码时应尽量让接口和方法保持单一职责,利于项目后期维护。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

单一职责(Simple Responsibility Pinciple,SRP)是指不要存在多于一个导致类变更的原因。假设我们有一个 Class 负责两个职责,一旦发生需求变更,修改其中一个职责的逻辑代码,有可能会导致另一个职责的功能发生故障。这样一来,这个 Class 存在两个导致类变更的原因。如何解决这个问题呢?我们就要给两个职责分别用两个 Class 来实现,进行解耦。后期需求变更维护互不影响。这样的设计,可以降低类的复杂度,提高类的可 读 性 ,提 高 系 统 的 可 维 护 性 , 降 低 变 更 引 起 的 风 险 。 总 体 来 说 就 是 一 个Class/Interface/Method 只负责一项职责。

接下来看一段代码:

/**
 * @author madongyu
 * @projectName design-pattern-ma
 * @description: TODO
 * @date 2019/6/1815:34
 */
public class Curriculum {
    public void study(String courseName){
        if("直播课".equals(courseName)){
            System.out.println(courseName + "不能快进");
        }else{
            System.out.println(courseName + "可以反复回看");
        }
    }

    public static void main(String[] args) {
        Curriculum curriculum = new Curriculum();
        //不同的职责
        curriculum.study("直播课");
        curriculum.study("录播课");
    }
}

从上面代码来看,Curriculum类承担了两种处理逻辑。假如,现在要对课程进行加密,那么直播课和录播课的加密逻辑都不一样,必须要修改代码。而修改代码逻辑势必会相互影响容易造成不可控的风险。我们对职责进行分离解耦,来看代码,分别创建两个类ReplayCurriculum 和 LiveCurriculum

代码如下:

/**
 * @author madongyu
 * @projectName design-pattern-ma
 * @description: TODO
 * @date 2019/6/1815:37
 */
public class ReplayCurriculum {
    public void study(String courseName){
        System.out.println(courseName + "可以反复回看");
    }
}
/**
 * @author madongyu
 * @projectName design-pattern-ma
 * @description: TODO
 * @date 2019/6/1815:37
 */
public class LiveCurriculum {
    public void study(String courseName){
        System.out.println(courseName + "不能快进");
    }
}
 public static void main(String[] args) {
        ReplayCurriculum replayCurriculum=new ReplayCurriculum();
        replayCurriculum.study("可以反复回看");

        LiveCurriculum liveCurriculum=new LiveCurriculum();
        liveCurriculum.study("不能快进");
    }

业务继续发展,课程要做权限。没有付费的学员可以获取课程基本信息,已经付费的学员可以获得视频流,即学习权限。那么对于控制课程层面上至少有两个职责。我们可以把展示职责和管理职责分离开来,都实现同一个抽象依赖。设计一个顶层接口,创建Curriculum接口:

/**
 * @author madongyu
 * @projectName design-pattern-ma
 * @description: TODO
 * @date 2019/6/1815:45
 */
public interface Curriculum {
    //获得基本信息
    String getCourseName();
    //获得视频流
    byte[] getCourseVideo();
    //学习课程
    void studyCourse();
    //退款
    void refundCourse();
}

我们可以把这个接口拆成两个接口,创建一个接口 ICurriculum 和 ICurriculumManager: ICurriculum 接口:

/**
 * @author madongyu
 * @projectName design-pattern-ma
 * @description: TODO
 * @date 2019/6/1815:46
 */
public interface ICurriculum {
    String getCourseName();
    byte[] getCourseVideo();
}

ICurriculumManager接口:

/**
 * @author madongyu
 * @projectName design-pattern-ma
 * @description: TODO
 * @date 2019/6/1815:46
 */
public interface ICurriculumManager {
    void studyCourse();
    void refundCourse();
}

下面我们来看一下方法层面的单一职责设计。有时候,我们为了偷懒,通常会把一个方法写成下面这样:

 下面我们来看一下方法层面的单一职责设计。有时候,我们为了偷懒,通常会把一个方法写成下面这样:

 public Curriculum(String name,String address) {
    }

    public Curriculum(String name,String address,boolean bool) {
        if(bool){

        }else {

        }
    }

显然,上面的 Curriculum()方法中都承担了多个职责,既可以修改 name,也可以修改 address,甚至更多,明显不符合单一职责。那么我们做如下修改,把这个方法拆成两个:

 public Curriculum(String name) {
        name="ma";
    }

    public Curriculum(String address) {
        address="北京";
    }

这修改之后,开发起来简单,维护起来也容易。但是,我们在实际开发中会项目依赖,组合,聚合这些关系,还有项目的规模,周期,技术人员的水平,对进度的把控,很多类都不符合单一职责。但是,我们在编写代码的过程,尽可能地让接口和方法保持单一职责,对我们项目后期的维护是有很大帮助的。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值