前言
迪米特法则,是一个非常实用的原则。利用这个原则,可以帮我们实现代码的 “高内聚、松耦合”。
围绕下面几个问题,来学习迪米特原则。
- 什么是 “高内聚、松耦合”?
- 如何利用迪米特法则来实现 高内聚、松耦合?
- 哪些代码设计是明显违背迪米特法则的?该如何重构?
什么是 “高内聚、松耦合”?
“高内聚、松耦合”是一个非常重要的思想,能有效地提高代码的可读性和可维护性,缩小功能改动导致的代码范围改动。
很多设计原则都已实现代码的“高内聚、松耦合”为目的,比如单一职责原则、基于接口而非实现编程。
在这个设计思想中,“高内聚” 用来指导类本身的设计,“松耦合” 用来指导类与类之间依赖关系的设计。不过,这两种并非独立不相干。高内聚有助于松耦合,松耦合有需要高内聚的支持。
什么是“高内聚”呢?
所谓高内聚,就是指相近的功能应该放到同一个类中,不相近的功能不要放到同一个类中。
相近的功能往往会被同时修改,放到同一个类中,修改会比较集中,代码容易维护。实际上,我们前面讲过的单一职责原则
是实现代码高内聚的非常有效的设计原则。
什么是“松耦合”?
松耦合是指,类与类之间的依赖关系简单清晰。即使两个类有依赖关系,一个类的代码改动不会或者很少导致依赖类的改动。
前面讲的依赖注入
、接口隔离
、基于接口而非实现编程
,以及今天的迪米特法则
,都是为了实现代码的松耦合。
“内聚” 和 “耦合” 之间的关系
“高内聚” 有助于 “松耦合”,同理 “低内聚” 也会导致 “紧耦合”。
上图的左边的代码结构是 “高内聚、松耦合”,右边部分是 “低内聚、紧耦合”。
- 左边部分的代码设计中,类的粒度较小,每个类的职责比较单一。相近的功能都放到了一个类中,不相近的功能被分割到了多个类中。这样类更加独立,代码的内聚性更高。因为职责单一,所以每个类被依赖的类就会比较少,代码低耦合。一个类的修改,只会影响到一个依赖类的代码改动。我们只需要测试依赖类是否还能正常工作就行了。
- 右边部分的代码设计中,类粒度较大,低内聚,功能大而全,不相近的功能放到一个类中。这就导致很多其他类都依赖这个类。当修改这个类的某一个功能代码时,会影响依赖它的多个类。我们需要测试这三个依赖类是否正常工作。这也就是所谓的 “牵一发而动全身”。
另外,从图中我们可以看出,高内聚、低耦合的代码结构更加简单、清晰,相应地,可维护性和可读性要好很多。
“迪米特法则”理论描述
迪米特法则,Law Of Demeter,缩写是 LOD,它也叫做最小知识原则。
这个原则的英文定义:
Each unit should haval only limited knwoledge about other units: only units “closely” related to the current unit. Or: Ecah unit should only talk to its friends; Don’t talk to strangers.
翻译:每个模块只应该了解与它关系紧密的模块的有限知识。或者说,每个模块只和自己的朋友 “说话”,不和陌生人说话。
我们把其中的模块,替换成类,按照自己的意思理解下:不该有直接依赖关系的类,不要有依赖;有依赖关系的类,尽量只依赖必要的接口。
从上面的描述中,我们可以看出,迪米特法则包含前后两部分,这两部分讲的是两件事,我们用两个实战案例讲解下。
理论解读与代码实战一 —— 不要有直接依赖关系的类,不要有依赖
我们举一个搜索引擎爬取网页的功能。代码中包含三个主要类。其中 NetworkTransporter
类负责底层网络通信,根据请求获取数据;HtmlDownloader
类用来通过 URL 获取网页;Document
表示网页文档,后续的网页内容抽取、分词、索引都是依次为处理对象。具体代码如下:
public class NetworkTransporter {// 省略属性和其他方法...public Byte[] send(HtmlRequest htmlRequest) { /*...*/ }
}public class HtmlDownloader {private NetworkTransporter transporter; // 通过构造函数注入...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
。
该如何重构,才能让 NetworkTransporter
类符合迪米特法则呢?应该把 HtmlRequest
类中的 address
和 content
交给 NetworkTransporter
,而非直接把 HtmlRequest
交给 NetworkTransporter
。按照这个思路,NetworkTransporter
重构之后的代码如下所示:
public class NetworkTransporter {// 省略属性和其他方法...public Byte[] send(String address, Byte[] data) { /*...*/ }
}
在看下 HtmlDownloader
类。这个类的设计没有问题。不过因为修改了 NetworkTransporter
,所以要对它做响应的改动。
public class HtmlDownloader {private NetworkTransporter transporter; // 通过构造函数注入...public Html downloadHtml(String url) {HtmlRequest htmlRequest = new HtmlRequest(url);Byte[] rawHtml = transporter.send(htmlRequest.getAddress(), htmlRequest.getContent().getBytes());return new Html(rawHtml);}
}
最后,看下 Document
类。 这个类的问题比较多,主要有三点。
- 第一:构造函数中的
downloader.downloadHtml(url)
逻辑复杂,耗时长,不应该放到构造函数中,会影响代码的可测试性。 - 第二:
HtmlDownloader
在构造函数中,通过 new 来创建,违反了基于接口而非实现编程的设计思想,也会影响到代码的可测试性。 - 第三:从业务角度上讲,
Document
网页文档没必要依赖HtmlDownloader
,违背迪米特法则。
不过,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 htmlDownloader;public DocumentFactory(HtmlDownloader htmlDownloader) {this.htmlDownloader = htmlDownloader;}public Document createDocument(String url) {Html html = htmlDownloader.downloadHtml(url);return new Document(url, html);}
}
理论解读与代码实战二 —— 有依赖关系的类,尽量只依赖必要的接口
现在在看下迪米特法则的后半部分:“有依赖关系的类,尽量只依赖必要的接口”。我们还是结合一个例子来讲解。下面这段代码非常简单, Serialization
类负责对象的序列化和反序列化。这个例子在之前单一职责原则笔记中,你可以结合一起看下。
public class Serialization {public String serialize(Object object) {String serializedResult = ...;// ...return serializedResult;}public Object deserialize(String str) {String 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) {String deserializedResult = ...;// ...return deserializedResult;}
}
不过,虽然拆分之后的代码更能满足迪米特法则,但却违背了高内聚的设计思想。高内聚要求相近的功能要放到同一个类中,这样可以方便功能修改的时候,修改的地方不至过于分散。对于刚刚的例子,如果我们修改了序列化的实现方式,比如从 JSON 换成了 XML,那反序列化的实现逻辑也需要修改。在未拆分的情况下,只要修改一个类即可。在拆分之后,需要修改两个类。显然,这种设计思路的代码改动范围变大了。
实际上,通过引入两个接口,就可以既不违背高内聚的设计思想,也不违背迪米特法则。具体的代码如下所示,实际上在讲解 “接口隔离原则”课程的时候,第三个例子就用了类似的思路。你可以结合着一块来看。
public interface Serializable {String serialize(Object object);
}public interface Deserializable {Object deserialize(String str);
}public class Serialization implements Serializable, Deserializable {@Overridepublic String serialize(Object object) {String serializedResult = ...;// ...return serializedResult;}@Overridepublic Object deserialize(String str) {String deserializedResult = ...;// ...return deserializedResult;}
}public class DemoClass_1 {private Serializable serializer;public DemoClass_1(Serializable serializer) {this.serializer = serializer;}// ...
}public class DemoClass_2 {private Deserializable deserializer;public DemoClass_2(Deserializable deserializer) {this.deserializer = deserializer;}// ...
}
尽管,还是要往 DemoClass_1
类的构造函数中,传入包含序列化和反序列化的 Serialization
实现类,但是我们依赖的 Serializable
接口只包含序列化操作, DemoClass_1
无法使用 Serialization
的发序列化接口,对反序列化操作无感知,这也就符合了迪米特法则后半部分所说的“依赖有限接口”的要求。
实际上,上面的代码思路,也体现了 “基于接口而非实现编程” 的设计原则,结合迪米特法则,我们可以总结出一个新的设计原则,那就是 “基于最小接口而非最大实现编程”。
辩证思考与灵活应用
Serialization
类只包含序列化和反序列化两个操作,只用到序列化操作的使用者,即便能够感知到反序列化接口,问题也不大。为了满足迪米特法则,我们将一个非常简单的类,拆分出两个接口,是否有过度设计的意思呢?
设计原则本身没错,只有是否用对之说。不要为了应用设计原则而应用设计原则,我们在应用设计原则时,一定要具体问题具体分析。
对于刚刚的 Serialization
来说,只包含两个操作,确实没有太大必要拆分成两个接口。但是,如果我们对 Serialization
类添加更多的功能,实现更多更好的序列化和反序列化函数,我们来重新思考下这个问题。修改后的代码如下所示:
public class Serialization {public String serialize(Object object) { /*...*/ }public String serialize(Map map) { /*...*/ }public String serialize(List list) { /*...*/ }public Object deserialize(String str) { /*...*/ }public Map deserialize(String str) { /*...*/ }public List deserialize(String str) { /*...*/ }
}
在这种场景下,第二种设计思路更好些。因为基于之前的应用常见来说,大部分代码只需要用到序列化的功能,这部分使用者,没有必要了解反序列化知识,而修改之后的 Serialization
的反序列化知识从一个变成三个。 一旦,反序列化操作有代码改动,我们都需要检查、测试所有依赖 Serialization
类的代码是否还能正常工作。为了减少耦合和测试工作量,我们应该按照迪米特法则,将反序列化和序列化功能隔离开。
总结
1.如何理解“高内聚、松耦合”
“高内聚、松耦合” 是一个非常重要的设计思想,能有效提高代码的可读性、可维护性,缩小功能改动导致的代码改动范围。“高内聚” 用来指导类本身的设计,“低耦合” 用来指导类与类之间的依赖关系的设计。
所谓高内聚,就是指相近的功能应该放到同一个类中,不相近的功能不要放到同一个类中。相近的功能往往会被同时修改,放到同一个类中,修改会比较集中。
所谓松耦合,是指,在代码中,类与类之间的依赖关系简单清晰。即使两个有类有依赖关系,一个类的改动也不会(或者很少)导致依赖类的代码改动。
2.如何理解“迪米特法则”
不该有直接依赖关系的类之间,不要有依赖关系;有依赖关系的类之间,尽量只依赖必要的接口。迪米特法则是希望减少类之间的耦合,让类越独立越好。每个类都应该少了解系统的其他部分。一旦发生变化,需要了解这一变化的类就会比较少。