Go设计模式学习——单一职责原则_go 文件职责不单一-CSDN博客

本文链接：https://blog.csdn.net/catkin_ws/article/details/122225701

1单一职责原则

1.1 含义

单一职责原则 (Single Responsibility Principle)(SRP)

A class or module should have a single responsibility.

一个类或者模块只负责完成一个职责（或者功能）。

把模块看作比类更加粗粒度的代码块，模块中包含多个类，多个类组成一个模块

1.2 理解

一个类只负责完成一个职责或者功能。不要设计大而全的类，要设计粒度小、功能单一的类。

单一职责原则是为了实现代码高内聚、低耦合，提高代码的复用性、可读性、可维护性。

换个角度来讲就是，一个类包含了两个或者两个以上业务不相干的功能，那我们就说它职责不够单一，应该将它拆分成多个功能更加单一、粒度更细的类。

1.3 举例

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

public class UserInfo {
  private long   userId;
  private String username;
  private String email;
  private String telephone;
  private long   createTime;
  private long   lastLoginTime;
  private String provinceOfAddress; // 省
  private String cityOfAddress; // 市
  private String regionOfAddress; // 区 
  private String detailedAddress; // 详细地址
  // ...省略其他属性和方法...
}

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

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

要从中做出选择，我们不能脱离具体的应用场景。

如果在这个社交产品中，用户的地址信息跟其他信息一样，只是单纯地用来展示，那 UserInfo 现在的设计就是合理的。
如果这个社交产品发展得比较好，之后又在产品中添加了电商的模块，用户的地址信息还会用在电商物流中，那最好将地址信息从 UserInfo 中拆分出来，独立成用户物流信息（或者叫地址信息、收货信息等）。
如果做这个社交产品的公司发展得越来越好，公司内部又开发出了很多其他产品（可以理解为其他 App）。公司希望支持统一账号系统，也就是用户一个账号可以在公司内部的所有产品中登录。这个时候就需要继续进行拆分UserInfo类，将跟身份认证相关的信息（比如，email、telephone 等）抽取成独立的类。

1.4 建议

不同的应用场景、不同阶段的需求背景、不同的业务层面，对同一个类的职责是否单一，可能会有不同的判定结果。实际上，一些侧面的判断指标更具有指导意义和可执行性，比如，出现下面这些情况就有可能说明这类的设计不满足单一职责原则：

类中的代码行数、函数或者属性过多；
类依赖的其他类过多，或者依赖类的其他类过多；
私有方法过多；比较难给类起一个合适的名字；
类中大量的方法都是集中操作类中的某几个属性。

这些判断指标并没有量化标准, 就像问大厨“放盐少许”中的“少许”是多少，大厨也很难给出一个特别具体的量值。

Suggestions

对于新手的话,给出一个凑活能用、比较宽泛的、可量化的标准，那就是一个类的代码行数最好不能超过 200 行，函数个数及属性个数都最好不要超过 10 个。
开发过程中, 我们可以先写一个粗粒度的类，满足业务需求。随着业务的发展，如果粗粒度的类越来越庞大，代码越来越多，这个时候，我们就可以将这个粗粒度的类，拆分成几个更细粒度的类。

1.5 职责越单一越好?

单一职责原则通过避免设计大而全的类，避免将不相关的功能耦合在一起，来提高类的内聚性。同时，类职责单一，类依赖的和被依赖的其他类也会变少，减少了代码的耦合性，以此来实现代码的高内聚、低耦合。

但是，如果拆分得过细，实际上会适得其反，反倒会降低内聚性，也会影响代码的可维护性。

举例:

/** 
* Protocol format: identifier-string;{gson string} 
* For example: UEUEUE;{"a":"A","b":"B"} 
*/
public class Serialization {
  private static final String IDENTIFIER_STRING = "UEUEUE;";
  private Gson gson;
  
  public Serialization() {
    this.gson = new Gson();
  }
  //序列化
  public String serialize(Map<String, String> object) {
    StringBuilder textBuilder = new StringBuilder();
    textBuilder.append(IDENTIFIER_STRING);
    textBuilder.append(gson.toJson(object));
    return textBuilder.toString();
  }
  //反序列化
  public Map<String, String> 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<String, String> 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<String, String> 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 类的代码，那就会导致序列化、反序列化不匹配，程序运行出错，也就是说，拆分之后，代码的可维护性变差了。