设计模式学习笔记 - 设计原则 - 8.迪米特法则（LOD）

前言

迪米特法则，是一个非常实用的原则。利用这个原则，可以帮我们实现代码的 “高内聚、松耦合”。

围绕下面几个问题，来学习迪米特法则。

• 什么是 “高内聚、松耦合”？
• 如何利用迪米特法则来实现 高内聚、松耦合？
• 哪些代码设计是明显违背迪米特法则的？该如何重构？

---

什么是 “高内聚、松耦合”？

“高内聚、松耦合”是一个非常重要的思想，能有效地提高代码的可读性和可维护性，缩小功能改动导致的代码范围改动。

很多设计原则都以实现代码的“高内聚、松耦合”为目的，比如单一职责原则、基于接口而非实现编程。

在这个设计思想中，“高内聚” 用来指导类本身的设计，“松耦合” 用来指导类与类之间依赖关系的设计。不过，这两种并非独立不相干。高内聚有助于松耦合，松耦合又需要高内聚的支持。

什么是“高内聚”呢？

所谓高内聚，就是指相近的功能应该放到同一个类中，不相近的功能不要放到同一个类中。

相近的功能往往会被同时修改，放到同一个类中，修改会比较集中，代码容易维护。实际上，我们前面讲过的单一职责原则是实现代码高内聚的非常有效的设计原则。

什么是“松耦合”？

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

前面讲的依赖注入、接口隔离、基于接口而非实现编程，以及今天的迪米特法则，都是为了实现代码的松耦合。

“内聚” 和 “耦合” 之间的关系

“高内聚” 有助于 “松耦合”，同理 “低内聚” 也会导致 “紧耦合”。

上图的左边的代码结构是 “高内聚、松耦合”，右边部分是 “低内聚、紧耦合”。

• 左边部分的代码设计中，类的粒度较小，每个类的职责比较单一。相近的功能都放到了一个类中，不相近的功能被分割到了多个类中。这样类更加独立，代码的内聚性更高。因为职责单一，所以每个类被依赖的类就会比较少，代码低耦合。一个类的修改，只会影响到一个依赖类的代码改动。我们只需要测试依赖类是否还能正常工作就行了。
• 右边部分的代码设计中，类粒度较大，低内聚，功能大而全，不相近的功能放到一个类中。这就导致很多其他类都依赖这个类。当修改这个类的某一个功能代码时，会影响依赖它的多个类。我们需要测试这三个依赖类是否正常工作。这也就是所谓的 “牵一发而动全身”。

另外，从图中我们可以看出，高内聚、低耦合的代码结构更加简单、清晰，相应地，可维护性和可读性要好很多。

“迪米特法则”理论描述

迪米特法则，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 {
    @Override
    public String serialize(Object object) {
        String serializedResult = ...;
        // ...
        return serializedResult;
    }
    
    @Override
    public 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.如何理解“迪米特法则”

不该有直接依赖关系的类之间，不要有依赖关系；有依赖关系的类之间，尽量只依赖必要的接口。迪米特法则是希望减少类之间的耦合，让类越独立越好。每个类都应该少了解系统的其他部分。一旦发生变化，需要了解这一变化的类就会比较少。