第二部分：理论一

第二部分：理论一

理论一

如何理解单一职责原则（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类中拆分出来。
• 所以对类的职责是否单一，也要看具体情况具体分析，没有一个明确的标准答案。
• 我们在开发过程中，可以先写一个粗粒度的类，随着业务的发展再进行细粒度拆分，也就是所谓是持续重构。

判断原则

1. 类中的代码行数、函数或属性过多，会影响代码的可读性和可维护性（一个类的代码行数最好不超过200行，方法和属性个数最好不超过10个）
2. 类依赖的其他类过多，或者依赖类的其他类过多，不符合高内聚、低耦合的设计思想
3. 私有方法过多，我们就要考虑能否将私有方法独立到新的类中，设置为 public 方法，供更多的类使用，从而提高代码的复用性
4. 比较难给类起一个合适名字，类的职责定义不够清晰
5. 类中大量的方法都是集中操作类中的某几个属性

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

• 为了满足单一职责原则，是不是把类拆得越细就越好呢？答案是否定的。
• 比如：一个简单协议的序列化和反序列化功能，拆分成两个类，虽然职责是更加单一了，但是如果修改协议格式等，那么就要修改两个类，内聚性降低了，可维护性也变差。

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);
	}
}