设计模式七大原则——单一职责原则

简介: 设计模式七大原则——单一职责原则

1.什么是单一职责原则?


首先我们可以对某个类来说,即一个类应该只负责一项职责。如类A负责两个不同职责: 职责1,职责2。当职责1需求变更而改变A时,可能造成职责2执行错误,所以需要将类A的粒度分解为A1A2

我们来看下面这段代码:👇👇👇

package com.szh.principle.singleresponsibility;
/**
 * 交通工具类
 *  方式1
 *  1. 在方式1的run方法中,违反了单一职责原则
 *  2. 解决的方案非常的简单,根据交通工具运行方法不同,分解成不同类即可
 */
class Vehicle {
    public void run(String vehicle) {
        System.out.println(vehicle + " 在公路上运行....");
    }
}
public class SingleResponsibility1 {
    public static void main(String[] args) {
        Vehicle vehicle = new Vehicle();
        vehicle.run("摩托车");
        vehicle.run("汽车");
        vehicle.run("飞机");
        vehicle.run("轮船");
    }
}

乍一看没什么问题吧,但是我们运行之后,看到的结果似乎就不太合乎思维逻辑了。摩托车、汽车在公路上运行肯定没问题,但是飞机和轮船呢???(你是故意找茬是不是?)

2.改进代码一


对于上面代码案例中的问题,想必大家也都看出来了,Vehicle这个类负责的职责太多了,它既要管摩托车、汽车这种在公路上跑的,还要去管飞机这种在天上飞的,这就使得Vehicle这个类粒度太粗了,后期如果做出对公路方法的修改时,可能还会影响到其他的业务功能。

所以我们考虑将Vehicle这个类进行分解,分解为多个类,各干各的、各司其职。

package com.szh.principle.singleresponsibility;
/**
 * 方案2的分析
 *   1. 遵守单一职责原则
 *   2. 但是这样做的改动很大,即将类分解,同时修改客户端
 *   3. 改进:直接修改Vehicle 类,改动的代码会比较少=>方案3
 */
class RoadVehicle {
    public void run(String vehicle) {
        System.out.println(vehicle + "在公路运行");
    }
}
class AirVehicle {
    public void run(String vehicle) {
        System.out.println(vehicle + "在天空运行");
    }
}
class WaterVehicle {
    public void run(String vehicle) {
        System.out.println(vehicle + "在水中运行");
    }
}
public class SingleResponsibility2 {
    public static void main(String[] args) {
        RoadVehicle roadVehicle = new RoadVehicle();
        roadVehicle.run("摩托车");
        roadVehicle.run("汽车");
        AirVehicle airVehicle = new AirVehicle();
        airVehicle.run("飞机");
        WaterVehicle waterVehicle = new WaterVehicle();
        waterVehicle.run("轮船");
    }
}

此时,我们将Vehicle拆解成了三个不同的类,再次运行。这样看起来就正常了吧。

不过也有人说,这样的改动比较大,也即直接在类的层面上做了修改,我们能不能不改动这个类,而是对它的方法做修改呢?答案是可以的。

3.改进代码二


package com.szh.principle.singleresponsibility;
/**
 * 方式3的分析
 *   1. 这种修改方法没有对原来的类做大的修改,只是增加方法
 *   2. 这里虽然没有在类这个级别上遵守单一职责原则,但是在方法级别上,仍然是遵守单一职责
 */
class Vehicle2 {
    public void runRoad(String vehicle) {
        System.out.println(vehicle + " 在公路上运行....");
    }
    public void runAir(String vehicle) {
        System.out.println(vehicle + " 在天空上运行....");
    }
    public void runWater(String vehicle) {
        System.out.println(vehicle + " 在水中行....");
    }
}
public class SingleResponsibility3 {
    public static void main(String[] args) {
        Vehicle2 vehicle2  = new Vehicle2();
        vehicle2.runRoad("汽车");
        vehicle2.runAir("飞机");
        vehicle2.runWater("轮船");
    }
}

此时我们并未将类进行拆解,而是将之前的run方法进行了拆解,虽然这样的代码没有在类的层面上遵守单一职责原则,但是它却在方法层面上遵守了单一职责原则,同样可以做到正确的结果。

4.单一职责原则总结


1.    降低类的复杂度,一个类只负责一项职责。

2.    提高类的可读性、可维护性。

3.    降低代码变更引起的风险。

4.    通常情况下,我们应当遵守单一职责原则。只有逻辑足够简单的情况下,才可以在代码级违反单一职责原则;而只有类中方法数量足够少的时候,才会建议在方法级别保持单一职责原则。

相关文章
|
1月前
|
设计模式
设计模式七大原则
这篇文章介绍了设计模式中的七大原则,特别强调了单一职责原则,即一个类应该只有一个引起其行为变化的原因,以确保类功能的高内聚和低耦合。
|
1月前
|
设计模式 存储 前端开发
React开发设计模式及原则概念问题之自定义Hooks的作用是什么,自定义Hooks设计时要遵循什么原则呢
React开发设计模式及原则概念问题之自定义Hooks的作用是什么,自定义Hooks设计时要遵循什么原则呢
|
6天前
|
设计模式 Java 关系型数据库
设计模式——设计模式简介和七大原则
设计模式的目的和核心原则、单一职责原则、接口隔离原则、依赖倒转原则、里氏替换原则、开闭原则、迪米特法则、合成复用原则
设计模式——设计模式简介和七大原则
|
3月前
|
设计模式 供应链
设计模式六大原则之迪米特法则
设计模式六大原则之迪米特法则
|
1月前
|
设计模式 算法 开发者
设计模式问题之最小知识原则(迪米特法则)对代码设计有何影响,如何解决
设计模式问题之最小知识原则(迪米特法则)对代码设计有何影响,如何解决
|
1月前
|
设计模式 前端开发 JavaScript
React开发设计模式及原则概念问题之什么是HOC(Higher-order component),HOC遵循的设计原则都有哪些
React开发设计模式及原则概念问题之什么是HOC(Higher-order component),HOC遵循的设计原则都有哪些
|
1月前
|
设计模式 前端开发 JavaScript
React开发设计模式及原则概念问题之什么是设计模式,单一职责原则如何理解
React开发设计模式及原则概念问题之什么是设计模式,单一职责原则如何理解
|
3月前
|
设计模式 uml
设计模式学习心得之前置知识 UML图看法与六大原则(下)
设计模式学习心得之前置知识 UML图看法与六大原则(下)
25 2
|
3月前
|
设计模式 Java 数据库
深入理解设计模式六大原则
深入理解设计模式六大原则
|
3月前
|
设计模式 数据可视化 程序员
设计模式学习心得之前置知识 UML图看法与六大原则(上)
设计模式学习心得之前置知识 UML图看法与六大原则(上)
28 0