第二部分:理论八

第二部分:理论八

理论八

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

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

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

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

我们再来看一下,什么是“松耦合”?

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

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

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

“迪米特法则”理论描述

  • 迪米特法则的英文翻译是: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) { //... }
}

posted @ 2021-10-04 15:40  起床睡觉  阅读(41)  评论(0编辑  收藏  举报