【Java设计模式 经典设计原则】七 LOD迪米特法则

花费了6篇Blog介绍了SOLID原则：SRP单一职责原则，OCP开闭原则，LSP里氏替换原则，ISP接口隔离原则，DIP依赖反转原则。以及常用的KISS简单编程原则、YAGNI勿过度设计原则和DRY勿重复编码原则。本篇BLog再附加一个常听到的法则：LOD迪米特法则

理解LOD迪米特法则

迪米特法则能够帮我们实现代码的高内聚、松耦合，首先我们需要明确下到底什么是高内聚、低耦合。

高内聚、松耦合是一个比较通用的设计思想，能够有效地提高代码的可读性和可维护性，缩小功能改动导致的代码改动范围。它可以用来指导不同粒度代码的设计与开发，比如系统、模块、类，甚至是函数，也可以应用到不同的开发场景中，比如微服务、框架、组件、类库等。如果具体到类就是：

• 高内聚，就是指相近的功能应该放到同一个类中，不相近的功能不要放到同一个类中。例如SRP单一职责原则就是高内聚思想的体现
• 松耦合，指在代码中，类与类之间的依赖关系简单清晰。即使两个类有依赖关系，一个类的代码改动不会或者很少导致依赖类的代码改动。例如依赖注入、接口隔离、基于接口而非实现编程、迪米特法则就是松耦合思想的体现

高内聚用来指导类本身的设计，松耦合用来指导类与类之间依赖关系的设计，高内聚有助于松耦合，松耦合又需要高内聚的支持

迪米特法则的英文翻译是：Law of Demeter，缩写是 LOD，翻译过来就是：最小知识原则或者最小知道原则

每个模块（unit）只应该了解那些与它关系密切的模块（units: only units “closely” related to the current unit）的有限知识（knowledge）。或者说，每个模块只和自己的朋友“说话”（talk），不和陌生人“说话”（talk）

模块替换成类来说表达的意思是：

不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口（也就是定义中的“有限知识”）

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

先来看下迪米特法则描述的前半部分：不该有直接依赖关系的类之间，不要有依赖，通过一个例子来解读类之间的依赖关系：这个例子实现了简化版的搜索引擎爬取网页的功能。代码中包含三个主要的类。其中，NetworkTransporter 类负责底层网络通信，根据请求获取数据；HtmlDownloader 类用来通过 URL 获取网页；Document 表示网页文档，后续的网页内容抽取、分词、索引都是以此为处理对象。具体的代码实现如下所示：

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);
  }
  //...
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

这个例子看起来是层层依赖，Document负责抽取html文档，依赖HtmlDownloader下载的网页，而HtmlDownloader下载网页又依赖NetworkTransporter 进行网络数据传输。NetworkTransporter 进行数据传输依赖HtmlRequest 对象。这就是一个紧耦合链条

NetworkTransporter通用化

作为一个底层网络通信类，我们希望它的功能尽可能通用，而不只是服务于下载 HTML，所以，不应该直接依赖太具体的发送对象 HtmlRequest。从这一点上讲，NetworkTransporter 类的设计违背迪米特法则，依赖了不该有直接依赖关系的 HtmlRequest 类，改造如下：

public class NetworkTransporter {
    // 省略属性和其他方法...
    public Byte[] send(String address, Byte[] data) {
      //...
    }
}
1
2
3
4
5
6
7

HtmlDownloader虽然依赖了NetworkTransporter的功能，但NetworkTransporter通用化后是可以直接依赖的，况且HtmlDownloader是针对Html的下载器，所以也无需通用化，所以只要对应处修改即可：

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);
  }
}
1
2
3
4
5
6
7
8
9
10
11
12

Document对HtmlDownloader依赖解除

从业务含义上来讲，Document 网页文档没必要依赖 HtmlDownloader 类，HtmlDownloader 对象在构造函数中通过 new 来创建而非通过依赖注入创建，这就导致了Document对HtmlDownloader的强依赖，Document 网页文档只能依赖HtmlDownloader下载器，这是紧耦合的。

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);
  }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

DocumentFactory 解耦了Document 和HtmlDownloader的关系，通过依赖注入HtmlDownloader获取HtmlDownloader对象，然后获取到html后传输给Document，这样Document对HtmlDownloader不需要有任何感知。

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

我们再来看一下这条原则中的后半部分：“有依赖关系的类之间，尽量只依赖必要的接口”。在学习SRP原则时也有过这个例子，

public class Serialization {
  public String serialize(Object object) {
    String serializedResult = ...;
    //...
    return serializedResult;
  }
  
  public Object deserialize(String str) {
    Object deserializedResult = ...;
    //...
    return deserializedResult;
  }
}
1
2
3
4
5
6
7
8
9
10
11
12
13

假设项目中，有些类只用到了序列化操作，而另一些类只用到反序列化操作。那基于迪米特法则后半部分“有依赖关系的类之间，尽量只依赖必要的接口”，只用到序列化操作的那部分类不应该依赖反序列化接口。同理，只用到反序列化操作的那部分类不应该依赖序列化接口

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

public class Deserializer {
  public Object deserialize(String str) {
    Object deserializedResult = ...;
    ...
    return deserializedResult;
  }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

但是如果我们修改了序列化的实现方式，比如从 JSON 换成了 XML，那反序列化的实现逻辑也需要一并修改，没有必要。所以改进一下重构方式，应用ISP原则隔离接口编程：

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;
  }
  //...
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

尽管还是要往 DemoClass_1 的构造函数中，传入包含序列化和反序列化的 Serialization 实现类，但是，依赖的 Serializable 接口只包含序列化操作，DemoClass_1 无法使用 Serialization 类中的反序列化接口，对反序列化操作无感知，这也就符合了迪米特法则后半部分所说的依赖有限接口的要求

当然这里的Serialization 类只有序列化和反序列化两个操作，所以也没必要过度设计拆分，但如果接口的功能方法比较多时，就要应用ISP拆分接口，让类只依赖有限接口

总结一下

SRP原则侧重高内聚，指导类功能的设计要单一，LOD法则侧重低耦合，指导类间依赖关系要松耦合，ISP原则是从调用者的角度出发确保接口的设计具备对调用者有良好的隔离性。基于接口而非实现编程思想也是从调用者的角度出发确保稳定的依赖和可插拔的实现。总的来说SRP原则、ISP原则、LOD法则以及基于接口而非实现编程思想的目标都是实现代码的高内聚低耦合，提高代码的可扩展性、可读性和可维护性。