第二部分:理论一
理论一
如何理解单一职责原则(SRP)?
- SOLID原则中的S指的就是单一职责原则
- SRP:Single Responsibility Principle(A class or module should have a single reponsibility)
- class类,module模块:
- 模块是比类更加抽象得概念,类也是模块
- 模块是比类更粗粒度得代码块,一个模块中包含多个类 -
- 单一职责原则:一个类只负责完成一个职责或者功能
- 比如:一个类里既包含订单的一些操作,又包含用户的一些操作。而订单和用户是两个独立的业务领域模型,那么就要拆分成两个粒度更细、功能更单一的:订单类和用户类
UserInfo 类:
public class UserInfo {
private long userId;
private String username;
private String email;
private String telephone;
private long createTime;
private long lastLoginTime;
private String avatarUrl;
private String provinceOfAddress; // 省
private String cityOfAddress; // 市
private String regionOfAddress; // 区
private String detailedAddress; // 详细地址
// ... 省略其他属性和方法...
}
如何判断类的职责是否足够单一?
通过案例分析
- 先提到上文中的例子,并不是每次都能这么明显看出订单和用户毫不相干,有时职责是否单一,是很难拿捏的。
- 文中举例,UserInfo类记录用户信息,那么用户地址信息在UserInfo类中,是否满足单一职责呢?
- 如果这个用户地址,只是用来展示,那么可以在UserInfo类中。如果用户地址还用于物流系统中,那么就要拆分出来。
- 更进一步,如果社区做大,那么用户身份验证等信息也要从UserInfo类中拆分出来。
- 所以对类的职责是否单一,也要看具体情况具体分析,没有一个明确的标准答案。
- 我们在开发过程中,可以先写一个粗粒度的类,随着业务的发展再进行细粒度拆分,也就是所谓是持续重构。
判断原则
- 类中的代码行数、函数或属性过多,会影响代码的可读性和可维护性(一个类的代码行数最好不超过200行,方法和属性个数最好不超过10个)
- 类依赖的其他类过多,或者依赖类的其他类过多,不符合高内聚、低耦合的设计思想
- 私有方法过多,我们就要考虑能否将私有方法独立到新的类中,设置为 public 方法,供更多的类使用,从而提高代码的复用性
- 比较难给类起一个合适名字,类的职责定义不够清晰
- 类中大量的方法都是集中操作类中的某几个属性
类的职责是否设计得越单一越好?
- 为了满足单一职责原则,是不是把类拆得越细就越好呢?答案是否定的。
- 比如:一个简单协议的序列化和反序列化功能,拆分成两个类,虽然职责是更加单一了,但是如果修改协议格式等,那么就要修改两个类,内聚性降低了,可维护性也变差。
Serialization 类实现了一个简单协议的序列化和反序列功能:
/**
* 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);
}
}
拆分成一个只负责序列化工作的 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);
}
}