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

    个人主页：金鳞踏雨

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

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

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

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

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

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

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

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

    案例分析

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

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

    1. class Employee {
    2.     private String name;
    3.     private String position;
    4.     private double baseSalary;
    5.  
    6.     public Employee(String name, String position, double baseSalary) {
    7.         this.name = name;
    8.         this.position = position;
    9.         this.baseSalary = baseSalary;
    10.     }
    11.  
    12.     // Getter 和 Setter 方法
    13.  
    14.     // 这些 calculateSalary()、saveEmployee() 最好不要放在这里面。
    15.     public double calculateSalary() {
    16.         // 计算员工工资的逻辑
    17.         return baseSalary * 1.2;
    18.     }
    19.  
    20.     public void saveEmployee() {
    21.         // 保存员工信息到数据库的逻辑
    22.     }
    23. }

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

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

    1. class Employee {
    2.     private String name;
    3.     private String position;
    4.     private double baseSalary;
    5.  
    6.     public Employee(String name, String position, double baseSalary) {
    7.         this.name = name;
    8.         this.position = position;
    9.         this.baseSalary = baseSalary;
    10.     }
    11.  
    12.     // Getter 和 Setter 方法
    13.     public double calculateSalary() {
    14.         // 计算员工工资的逻辑
    15.         return baseSalary * 1.2;
    16.     }
    17. }
    18.  
    19. class EmployeeRepository {
    20.     public void saveEmployee(Employee employee) {
    21.         // 保存员工信息到数据库的逻辑
    22.     }
    23. }

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

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

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

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

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

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

    案例分析

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

    1. public class UserInfo {
    2.     private long userId;
    3.     private String username;
    4.     private String email;
    5.     private String telephone;
    6.     private String avatarUrl;
    7.     private String province; // 省
    8.     private String cityOf; // 市
    9.     private String region; // 区 
    10.     private String detailedAddress; // 详细地址
    11.     // ... 省略其他属性和方法...
    12. }

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

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

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

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

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

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

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

    答案是否定的。

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

    1. public class Serialization {
    2. 	private static final String IDENTIFIER_STRING = "UEUEUE;";
    3. 	private Gson gson;
    4.  
    5. 	public Serialization() {
    6. 		this.gson = new Gson();
    7. 	}
    8.  
    9. 	// 序列化
    10. 	public String serialize(Map object) {
    11. 		StringBuilder textBuilder = new StringBuilder();
    12. 		textBuilder.append(IDENTIFIER_STRING);
    13. 		textBuilder.append(gson.toJson(object));
    14. 		return textBuilder.toString();
    15. 	}
    16.  
    17. 	// 反序列化
    18. 	public Map deserialize(String text) {
    19. 		if (!text.startsWith(IDENTIFIER_STRING)) {
    20. 			return Collections.emptyMap();
    21. 		}
    22. 		String gsonStr = text.substring(IDENTIFIER_STRING.length());
    23. 		return gson.fromJson(gsonStr, Map.class);
    24. 	}
    25. }

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

    1. // 序列化
    2. public class Serializer {
    3.     private static final String IDENTIFIER_STRING = "UEUEUE;";
    4.     private Gson gson;
    5.     
    6.     public Serializer() {
    7.     	this.gson = new Gson();
    8.     }
    9.   
    10.     public String serialize(Map object) {
    11.         StringBuilder textBuilder = new StringBuilder();
    12.         textBuilder.append(IDENTIFIER_STRING);
    13.         textBuilder.append(gson.toJson(object));
    14.         return textBuilder.toString();
    15.     }
    16. }
    17.  
    18. // 反序列化
    19. public class Deserializer {
    20.     private static final String IDENTIFIER_STRING = "UEUEUE;";
    21.     private Gson gson;
    22.     
    23.     public Deserializer() {
    24.     	this.gson = new Gson();
    25.     }
    26.   
    27.     public Map deserialize(String text) {
    28.     if (!text.startsWith(IDENTIFIER_STRING)) {
    29.         return Collections.emptyMap();
    30.     }
    31.     String gsonStr = text.substring(IDENTIFIER_STRING.length());
    32.     return gson.fromJson(gsonStr, Map.class);
    33.     }
    34. }

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

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

  • 相关阅读:
    前端实现实时消息提醒消息通知
    2024/6/5(页面静态化,熔断降级,降级处理,ES搜索实例,课程信息同步,认证授权,单点登录,Spring Security,OAuth2,授权模式)
    maven-jar-plugin maven打包插件笔记
    来聊一聊 Promise 的错误重载
    要写论文了，怎么搞？
    DCDC: 环路稳定性的测量方法-穿越频率和相位裕度
    完全彻底的卸载MySQL5.7.35
    [论文阅读]A ConvNet for the 2020s
    HPA总结
    2022 弱口令安全实验室招新赛-靶机挑战记录
  • 原文地址：https://blog.csdn.net/weixin_43715214/article/details/134001660