第二部分：理论八

第二部分：理论八

理论八

何为“高内聚、松耦合”？

• “高内聚、松耦合”是一个非常重要的设计思想，能够有效地提高代码的可读性和可维护性，缩小功能改动导致的代码改动范围。
• “高内聚”用来指导类本身的设计，“松耦合”用来指导类与类之间依赖关系的设计。

那到底什么是“高内聚”呢？

• 所谓高内聚，就是指相近的功能应该放到同一个类中，不相近的功能不要放到同一个类中。
• 相近的功能往往会被同时修改，放到同一个类中，修改会比较集中，代码容易维护。

我们再来看一下，什么是“松耦合”？

• 所谓松耦合是说，在代码中，类与类之间的依赖关系简单清晰。
• 即使两个类有依赖关系，一个类的代码改动不会或者很少导致依赖类的代码改动。

最后，我们来看一下，“内聚”和“耦合”之间的关系。

• 文中举例，通过两张图来对比。
• 左图中，类的粒度比较小，每个类的职责都比较单一。相近的功能都放到了一个类中，不相近的功能被分割到了多个类中。这样类更加独立，代码的内聚性更好。因为职责单一，所以每个类被依赖的类就会比较少，代码低耦合。一个类的修改，只会影响到一个依赖类的代码改动。我们只需要测试这一个依赖类是否还能正常工作就行了。
• 右图中，类粒度比较大，低内聚，功能大而全，不相近的功能放到了一个类中。这就导致很多其他类都依赖这个类。当我们修改这个类的某一个功能代码的时候，会影响依赖它的多个类。我们需要测试这三个依赖类，是否还能正常工作。这也就是所谓的“牵一发而动全身”。
• 另外，高内聚、低耦合的代码结构更加简单、清晰，相应地，在可维护性和可读性上确实要好很多。

“迪米特法则”理论描述

• 迪米特法则的英文翻译是：Law of Demeter，缩写是LOD。
• 还有另外一个更加达意的名字，叫作最小知识原则，英文翻译为：The Least Knowledge Principle。
• 每个模块（unit）只应该了解那些与它关系密切的模块（units: only units “closely” related to the current unit）的有限知识（knowledge）。或者说，每个模块只和自己的朋友“说话”（talk），不和陌生人“说话”（talk）。
• 不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口（也就是定义中的“有限知识”）。

不该有直接依赖关系的类之间，不要有依赖

文中举例

• 简化版的搜索引擎爬取网页的功能，包含三个类。
• NetworkTransporter 类负责底层网络通信，根据请求获取数据，有方法 send(HtmlRequest htmlRequest)
• HtmlDownloader 类用来通过 URL 获取网页，有方法downloadHtml()，其中调用NetworkTransporter.send()
• Document 类表示网页文档，后续的网页内容抽取、分词、索引都是以此为处理对象，构造方法中调用HtmlDownloader.downloadHtml()。

代码示例：

public class NetworkTransporter {
	// 省略属性和其他方法...
	public Byte[] send(HtmlRequest htmlRequest) {
		//...
	}
}
public class HtmlDownloader {
	private NetworkTransporter transporter;// 通过构造函数或 IOC 注入
	public Html downloadHtml(String url) {
		Byte[] rawHtml = transporter.send(new HtmlRequest(url));
		return new Html(rawHtml);
	}
}
public class Document {
	private Html html;
	private String url;
	public Document(String url) {
		this.url = url;
		HtmlDownloader downloader = new HtmlDownloader();
		this.html = downloader.downloadHtml(url);
	}
	//...
}

问题分析

• NetworkTransporter 类：
  • 作为一个底层网络通信类，不只是服务于下载 HTML，所以，我们不应该直接依赖太具体的发送对象 HtmlRequest。
  • 违背迪米特法则，依赖了不该有直接依赖关系的 HtmlRequst 类。
  • 去商店买东西不能直接把钱包给收银员，而是把钱从钱包里拿出来给收银员，应该把 HtmlRequst 里的 address 和 content 交给 NetworkTransporter。
• HtmlDownloader 类：
  • 设计没有问题，只需要对应修改调用NetworkTransporter.send() 的参数。
• Document 类：
  • 构造方法中逻辑过于复杂，耗时长，增加测试复杂度。
  • 构造方法中 new 了类 HtmlDownloader，违反了基于接口而非实现编程。
  • Document 网页文档没必要依赖 HtmlDownloader 类，违背了迪米特法则。
  • 增加一个工厂类 DocumentFactory 来创建 Document，构造方法中传入 HtmlDownloader，在方法 createDocument() 中new Document()。

NetworkTransporter 类代码修改后：

public class NetworkTransporter {
	// 省略属性和其他方法...
	public Byte[] send(String address, Byte[] data) {
		//...
	}
}

HtmlDownloader 类代码修改后：

public class HtmlDownloader {
	private NetworkTransporter transporter;// 通过构造函数或 IOC 注入
	// HtmlDownloader 这里也要有相应的修改
	public Html downloadHtml(String url) {
		HtmlRequest htmlRequest = new HtmlRequest(url);
		Byte[] rawHtml = transporter.send(htmlRequest.getAddress(), htmlRequest.getContent().getBytes());
		return new Html(rawHtml);
	}
}

Document 类代码修改后：

public class Document {
	private Html html;
	private String url;
	public Document(String url, Html html) {
		this.html = html;
		this.url = url;
	}
	//...
}
// 通过一个工厂方法来创建 Document
public class DocumentFactory {
	private HtmlDownloader downloader;
	public DocumentFactory(HtmlDownloader downloader) {
		this.downloader = downloader;
	}
	public Document createDocument(String url) {
		Html html = downloader.downloadHtml(url);
		return new Document(url, html);
	}
}

有依赖关系的类之间，尽量只依赖必要的接口

文中举例

• Serialization 类负责对象的序列化和反序列化。
• Serialization 类中有方法 serialize() 和 deserialize()。
• 单看这个类没问题，但是放在一定的应用场景中，我们的项目中有些类只用到序列化，有些类只用到反序列化。违背迪米特法则后半部分“有依赖关系的类之间，尽量只依赖必要的接口“。

Serialization 类代码：

public class Serialization {
	public String serialize(Object object) {
		String serializedResult = ...;
		//...
		return serializedResult;
	}
	public Object deserialize(String str) {
		Object deserializedResult = ...;
		//...
		return deserializedResult;
	}
}

Serialization 类拆分为两个更小粒度的类，一个只负责序列化（Serializer 类），一个只负责反序列化（Deserializer 类）:

public class Serializer {
	public String serialize(Object object) {
		String serializedResult = ...;
		...
		return serializedResult;
	}
}
public class Deserializer {
	public Object deserialize(String str) {
		Object deserializedResult = ...;
		...
		return deserializedResult;
	}
}

尽管拆分之后的代码更能满足迪米特法则，但却违背了高内聚的设计思想。如果修改了序列化的实现方式，比如从 JSON 换成了 XML，那反序列化的实现逻辑也需要一并修改。通过引入两个接口解决这个问题，具体的代码如下所示：

public interface Serializable {
	String serialize(Object object);
}
public interface Deserializable {
	Object deserialize(String text);
}
public class Serialization implements Serializable, Deserializable {
	@Override
	public String serialize(Object object) {
		String serializedResult = ...;
		...
		return serializedResult;
	}
	@Override
	public Object deserialize(String str) {
		Object deserializedResult = ...;
		...
		return deserializedResult;
	}
}
public class DemoClass_1 {
	private Serializable serializer;
	public Demo(Serializable serializer) {
		this.serializer = serializer;
	}
	//...
}
public class DemoClass_2 {
	private Deserializable deserializer;
	public Demo(Deserializable deserializer) {
		this.deserializer = deserializer;
	}
	//...
}

迪米特法优化

• 拆分成两个类，一个只负责序列化（Serializer 类），一个只负责反序列化（Deserializer 类）。
• 但是此方案违背高内聚的设计思想，相近的功能要放到同一个类中，这样可以方便功能修改的时候，修改的地方不至于过于分散。

接口隔离优化

• 引入两个接口，Serializable 和 Deserializable。
• 类 Serialization 实现以上两个接口中的序列化和反序列化方法。
• 在调用时，虽然传入包含序列化和反序列化的 Serialization 实现类，但是需要用到序列化就依赖 Serializable 接口，需要用到反序列化就依赖 Deserializable。
• 基于最小接口而非最大实现编程。

辩证思考与灵活应用

• 以上例子中，整个类只包含序列化和反序列化两个操作，只用到序列化操作的使用者，即便能够感知到仅有的一个反序列化函数，问题也不大。是否过度设计呢？
• 只包含两个操作，确实没有太大必要拆分成两个接口，如果添加更多序列化和反序列化的方法，那么拆分就很有必要。
• 序列化的使用者，没有必要了解反序列化的”知识“，按照迪米特法则，将反序列化和序列化的功能隔离开来，减少耦合和测试工作量。

代码示例：

public class Serializer { // 参看 JSON 的接口定义
	public String serialize(Object object) { //... }
	public String serializeMap(Map map) { //... }
	public String serializeList(List list) { //... }
	public Object deserialize(String objectString) { //... }
	public Map deserializeMap(String mapString) { //... }
	public List deserializeList(String listString) { //... }
}