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

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

单一职责原则

1、单一职责介绍



单一职责原则(SRP:Single Responsibility Principle)是指一个类或模块只负责单一的功能,不要存在多个导致类变更的原因。这个原则的核心思想就是将功能进行解耦,让单个类或模块只完成一项职责。)

简单来说:就是一个类只负责一个功能。


2、User用户例子

例如,一个User类应只关心表示用户本身的属性和行为,而不要将其它与用户无关的内容加入到这个类中去。如果一个类同时还负责了其他不相关的功能,比如用户地址、账户信息等,那么这个类的职责就不够单一了。这样,一旦修改了其中一个功能,可能就会影响到另外的功能,增加了维护和扩展的难度。

// 不遵循单一职责原则的代码实现
public class User {
    private String name;   // 姓名
    private String email;   // 邮箱
    private String address;  // 地址
    private double balance; // 收入
    public void updateUserInfo(String name, String email, String address) {
        this.name = name;
        this.email = email;
        this.address = address;
        // 更新用户信息...
    }
    public void deposit(double amount) {
        this.balance += amount;
        // 存款操作...
    }
}

在这个示例中,我们可以看到User类有两个职责:保存用户信息和用户账户操作。这就不符合单一职责原则,如果我们需要修改其中一个职责,可能会影响到另外一个职责的实现。

将上面用户的信息和用户账号的信息分离开

// 遵循单一职责原则的代码实现
public class User {
    private String name;
    private String email;
    private String address;
    public void updateUserInfo(String name, String email, String address) {
        this.name = name;
        this.email = email;
        this.address = address;
        // 更新用户信息...
    }
}
public class Account {
    private double balance;
    public void deposit(double amount) {
        this.balance += amount;
        // 存款操作...
    }
}


通过将用户信息和账户操作分别封装到不同的类中,我们使得每个类都只关注自己的职责,降低了代码间的耦合度,并且修改和扩展也更加方便和容易。

如果还是不太明白,再看下面的列子


3、交通工具列子

先看一段代码:

/**
 * 交通工具类
 *  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("轮船");
    }
}


运行结果如下:


观察发现,这样的结果似乎不太符合我们的日常生活的习惯啊。摩托车、汽车在公路上运行肯定没问题,但是飞机和轮船呢???

3.1 改进一


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


所以我们考虑将Vehicle这个类进行分解,分解为多个类,各干各的、各司其职。在类定义上实现单一职责原则:不同的类,做不同的事情,但是每个类里面做的事情都相同的。

/**
 *   1. 遵守单一职责原则
 *   2. 但是这样做的改动很大,即将类分解,同时修改客户端
 *   3. 改进:直接修改Vehicle 类
 */
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拆解成了三个不同的类,再次运行。这样看起来就正常了吧。

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

a731d0b4ef9f033e21c543b01671c791.png


3.2 改进二

在方法定义上实现单一职责原则:不同的方法,做不同的事情,但是每个方法里面做的事情都相同的。

/**
 *   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、单一职责原则总结


如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏


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

降低代码的耦合度,降低代码变更引起的风险

提高类的可读性、可维护性、清晰、可扩展

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

。这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏


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

降低代码的耦合度,降低代码变更引起的风险

提高类的可读性、可维护性、清晰、可扩展

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


目录
相关文章
|
5天前
|
设计模式
设计模式七大原则
这篇文章介绍了设计模式中的七大原则,特别强调了单一职责原则,即一个类应该只有一个引起其行为变化的原因,以确保类功能的高内聚和低耦合。
|
4天前
|
设计模式 存储 前端开发
React开发设计模式及原则概念问题之自定义Hooks的作用是什么,自定义Hooks设计时要遵循什么原则呢
React开发设计模式及原则概念问题之自定义Hooks的作用是什么,自定义Hooks设计时要遵循什么原则呢
|
3天前
|
设计模式 算法 Java
Java编程中的设计模式:简化复杂性的艺术
在Java的世界中,设计模式如同一位智慧的导师,指引着开发者们在复杂的编码迷宫中找到出口。本文将深入浅出地探讨几种常见的设计模式,通过实例演示如何在Java项目实践中运用这些模式,从而提升代码的可维护性和扩展性。无论你是新手还是资深开发者,这篇文章都将为你打开一扇通往高效编码的大门。
12 1
|
6天前
|
设计模式 安全 Java
|
3天前
|
设计模式 存储 Java
掌握Java设计模式的23种武器(全):深入解析与实战示例
掌握Java设计模式的23种武器(全):深入解析与实战示例
|
4天前
|
设计模式 算法 开发者
设计模式问题之最小知识原则(迪米特法则)对代码设计有何影响,如何解决
设计模式问题之最小知识原则(迪米特法则)对代码设计有何影响,如何解决
|
4天前
|
设计模式 前端开发 JavaScript
React开发设计模式及原则概念问题之什么是HOC(Higher-order component),HOC遵循的设计原则都有哪些
React开发设计模式及原则概念问题之什么是HOC(Higher-order component),HOC遵循的设计原则都有哪些
|
4天前
|
设计模式 前端开发 JavaScript
React开发设计模式及原则概念问题之什么是设计模式,单一职责原则如何理解
React开发设计模式及原则概念问题之什么是设计模式,单一职责原则如何理解
|
5天前
|
设计模式 安全 Java
怎样才能学好 Java 设计模式?
本文探讨了在软件开发中对设计模式的常见误解。许多人认为设计模式过于抽象难以学习,或是应用场景有限难以在复杂的业务环境中应用,甚至有人误以为所有问题都能通过设计模式解决。实际上,设计模式旨在解决特定范围内的面向对象设计问题,如提高代码的可复用性。为了正确理解和应用设计模式,需要摆正心态、深入了解其背景知识、培养独立思考的习惯,并坚持不懈地学习和实践。通过这些方法,开发者可以更好地掌握设计模式,从而在实际项目中做出更加合理的设计决策。
|
5天前
|
设计模式 Java
【Java】单例设计模式
【Java】单例设计模式