标签：String 第二 理论 private gson IDENTIFIER 部分 public STRING

第二部分：理论一

理论一

如何理解单一职责原则（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);
	}
}

标签：String,第二,理论,private,gson,IDENTIFIER,部分,public,STRING
来源： https://www.cnblogs.com/sleepday/p/15363235.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。