【23种设计模式】单一职责原则

个人主页:金鳞踏雨

个人简介:大家好,我是金鳞,一个初出茅庐的Java小白

目前状况:22届普通本科毕业生,几经波折了,现在任职于一家国内大型知名日化公司,从事Java开发工作

我的博客:这里是CSDN,是我学习技术,总结知识的地方。希望和各位大佬交流,共同进步 ~

一、如何理解单一职责原则?

单一职责原则(Single Responsibility Principle,简称SRP),它要求一个模块应该只负责一个特定的功能。这有助于降低类之间的耦合度提高代码的可读性和可维护性

我们可以把模块看作比类更加抽象的概念,类也可以看作模块。或者把模块看作比类更加粗粒度的代码块,模块中包含多个类,多个类组成一个模块。

单一职责原则的定义描述非常简单,也不难理解。一个类只负责完成一个职责或者功能。

不要设计大而全的类,要设计粒度小、功能单一的类。一个类包含了两个或者两个以上业务不相干的功能,那我们就说它职责不够单一,应该将它拆分成多个功能更加单一、粒度更细的类。

案例分析

假设我们需要实现一个员工管理系统,处理员工的信息和工资计算

不遵循单一职责原则的实现可能如下:

class Employee {
    private String name;
    private String position;
    private double baseSalary;

    public Employee(String name, String position, double baseSalary) {
        this.name = name;
        this.position = position;
        this.baseSalary = baseSalary;
    }

    // Getter 和 Setter 方法

    // 这些 calculateSalary()、saveEmployee() 最好不要放在这里面。
    public double calculateSalary() {
        // 计算员工工资的逻辑
        return baseSalary * 1.2;
    }

    public void saveEmployee() {
        // 保存员工信息到数据库的逻辑
    }
}

上面的代码中,Employee 类负责了员工信息的管理、工资计算以及员工信息的持久化,这违反了单一职责原则

为了遵循该原则,我们可以将这些功能拆分到不同的类中!

class Employee {
    private String name;
    private String position;
    private double baseSalary;

    public Employee(String name, String position, double baseSalary) {
        this.name = name;
        this.position = position;
        this.baseSalary = baseSalary;
    }

    // Getter 和 Setter 方法
    public double calculateSalary() {
        // 计算员工工资的逻辑
        return baseSalary * 1.2;
    }
}

class EmployeeRepository {
    public void saveEmployee(Employee employee) {
        // 保存员工信息到数据库的逻辑
    }
}

在遵循单一职责原则的代码中,我们将员工信息的持久化操作从 Employee 类中抽离出来,放到了一个新的 EmployeeRepository 类中。现在,Employee 类只负责员工信息的管理和工资计算,而 EmployeeRepository 类负责员工信息的持久化操作。这样,每个类都只关注一个特定的职责,更易于理解、维护和扩展。

遵循单一职责原则有助于提高代码的可读性、可维护性和可扩展性。请注意,这个原则并不是绝对的,需要根据具体情况来判断是否需要拆分类和模块。过度拆分可能导致过多的类和模块,反而增加系统的复杂度。

二、如何判断类的职责是否足够单一?

"单一"并没有一个绝对的标准答案,一切应该围绕实际业务出发。一旦一个看似很单一的模块,业务逻辑足够大,大部分情况,它都可以继续细分。"单一"是相对的!

从刚刚这个例子来看,单一职责原则看似不难应用。

但大部分情况下,类里的方法是归为同一类功能,还是归为不相关的两类功能并不是那么容易判定的。在真实的软件开发中,对于一个类是否职责单一的判定,是很难拿捏的。

案例分析

在一个社交产品中,我们用下面的 UserInfo 类来记录用户的信息。你觉得,UserInfo 类的设计是否满足单一职责原则呢?

public class UserInfo {
    private long userId;
    private String username;
    private String email;
    private String telephone;
    private String avatarUrl;
    private String province; // 省
    private String cityOf; // 市
    private String region; // 区 
    private String detailedAddress; // 详细地址
    // ... 省略其他属性和方法...
}

对于这个问题,有两种不同的观点。

  • 一种观点是:UserInfo 类包含的都是跟用户相关的信息,所有的属性和方法都隶属于用户这样一个业务模型,满足单一职责原则;
  • 另一种观点是:地址信息在 UserInfo 类中,所占的比重比较高,可以继续拆分成独立的 Address 类,UserInfo 只保留除 Address 之外的其他信息,拆分之后的两个类的职责更加单一。

哪种观点更对呢?实际上,要从中做出选择,我们不能脱离具体的应用场景。如果在这个社交产品中,用户的地址信息跟其他信息一样,只是单纯地用来展示,那 UserInfo 现在的设计就是合理的。但是,如果这个社交产品发展得比较好,之后又在产品中添加了电商的模块,用户的地址信息还会用在电商物流中,那我们最好将地址信息从 UserInfo 中拆分出来,独立成用户物流信息(或者叫地址信息、收货信息等)。

所以,我么还有记住一句话,脱离了业务谈设计是耍流氓,事实上脱离了业务谈什么都是耍流氓,技术服务于业务这是亘古不变的道理!!!

在软件开发过程中,我们可以先写一个粗粒度的类,满足业务需求。随着业务的发展,如果粗粒度的类越来越庞大,代码越来越多,这个时候,我们就可以将这个粗粒度的类,拆分成几个更细粒度的类。这就是所谓的持续重构

三、类的职责是否设计得越单一越好?

为了满足单一职责原则,是不是把类拆得越细就越好呢?

答案是否定的。

Serialization 类实现了一个简单协议的序列化和反序列功能,具体代码如下:

public class Serialization {
	private static final String IDENTIFIER_STRING = "UEUEUE;";
	private Gson gson;

	public Serialization() {
		this.gson = new Gson();
	}

	// 序列化
	public String serialize(Map object) {
		StringBuilder textBuilder = new StringBuilder();
		textBuilder.append(IDENTIFIER_STRING);
		textBuilder.append(gson.toJson(object));
		return textBuilder.toString();
	}

	// 反序列化
	public Map deserialize(String text) {
		if (!text.startsWith(IDENTIFIER_STRING)) {
			return Collections.emptyMap();
		}
		String gsonStr = text.substring(IDENTIFIER_STRING.length());
		return gson.fromJson(gsonStr, Map.class);
	}
}

如果我们想让类的职责更加单一,我们对 Serialization 类进一步拆分,拆分成一个只负责序列化工作的 Serializer 类和另一个只负责反序列化工作的 Deserializer 类。

// 序列化
public class Serializer {
    private static final String IDENTIFIER_STRING = "UEUEUE;";
    private Gson gson;
    
    public Serializer() {
    	this.gson = new Gson();
    }
  
    public String serialize(Map object) {
        StringBuilder textBuilder = new StringBuilder();
        textBuilder.append(IDENTIFIER_STRING);
        textBuilder.append(gson.toJson(object));
        return textBuilder.toString();
    }
}

// 反序列化
public class Deserializer {
    private static final String IDENTIFIER_STRING = "UEUEUE;";
    private Gson gson;
    
    public Deserializer() {
    	this.gson = new Gson();
    }
  
    public Map deserialize(String text) {
    if (!text.startsWith(IDENTIFIER_STRING)) {
        return Collections.emptyMap();
    }
    String gsonStr = text.substring(IDENTIFIER_STRING.length());
    return gson.fromJson(gsonStr, Map.class);
    }
}

虽然经过拆分之后,Serializer 类和 Deserializer 类的职责更加单一了,但也随之带来了新的问题。如果我们修改了协议的格式,数据标识从“UEUEUE”改为“DFDFDF”,或者序列化方式从 JSON 改为了 XML,那 Serializer 类和 Deserializer 类都需要做相应的修改,代码的内聚性显然没有原来 Serialization 高了。而且,如果我们仅仅对 Serializer 类做了协议修改,而忘记了修改 Deserializer 类的代码,那就会导致序列化、反序列化不匹配,程序运行出错,也就是说,拆分之后,代码的可维护性变差

实际上,不管是应用设计原则还是设计模式,最终的目的还是提高代码的可读性、可扩展性、复用性、可维护性等。我们在考虑应用某一个设计原则是否合理的时候,也可以以此作为最终的考量标准。

你可能感兴趣的:(23种设计模式,设计模式,java,数据库,单一原则)