马鞍山网站建设专业制,iis发布网站的教程,最新seo课程,各大网站查重率比较前言
迪米特法则#xff0c;是一个非常实用的原则。利用这个原则#xff0c;可以帮我们实现代码的 “高内聚、松耦合”。
围绕下面几个问题#xff0c;来学习迪米特原则。
什么是 “高内聚、松耦合”#xff1f;如何利用迪米特法则来实现 高内聚、松耦合#xff1f;哪些…前言
迪米特法则是一个非常实用的原则。利用这个原则可以帮我们实现代码的 “高内聚、松耦合”。
围绕下面几个问题来学习迪米特原则。
什么是 “高内聚、松耦合”如何利用迪米特法则来实现 高内聚、松耦合哪些代码设计是明显违背迪米特法则的该如何重构 什么是 “高内聚、松耦合”
“高内聚、松耦合”是一个非常重要的思想能有效地提高代码的可读性和可维护性缩小功能改动导致的代码范围改动。 很多设计原则都已实现代码的“高内聚、松耦合”为目的比如单一职责原则、基于接口而非实现编程。 在这个设计思想中“高内聚” 用来指导类本身的设计“松耦合” 用来指导类与类之间依赖关系的设计。不过这两种并非独立不相干。高内聚有助于松耦合松耦合有需要高内聚的支持。
什么是“高内聚”呢
所谓高内聚就是指相近的功能应该放到同一个类中不相近的功能不要放到同一个类中。
相近的功能往往会被同时修改放到同一个类中修改会比较集中代码容易维护。实际上我们前面讲过的单一职责原则是实现代码高内聚的非常有效的设计原则。
什么是“松耦合”
松耦合是指类与类之间的依赖关系简单清晰。即使两个类有依赖关系一个类的代码改动不会或者很少导致依赖类的改动。
前面讲的依赖注入、接口隔离、基于接口而非实现编程以及今天的迪米特法则都是为了实现代码的松耦合。
“内聚” 和 “耦合” 之间的关系
“高内聚” 有助于 “松耦合”同理 “低内聚” 也会导致 “紧耦合”。 上图的左边的代码结构是 “高内聚、松耦合”右边部分是 “低内聚、紧耦合”。
左边部分的代码设计中类的粒度较小每个类的职责比较单一。相近的功能都放到了一个类中不相近的功能被分割到了多个类中。这样类更加独立代码的内聚性更高。因为职责单一所以每个类被依赖的类就会比较少代码低耦合。一个类的修改只会影响到一个依赖类的代码改动。我们只需要测试依赖类是否还能正常工作就行了。右边部分的代码设计中类粒度较大低内聚功能大而全不相近的功能放到一个类中。这就导致很多其他类都依赖这个类。当修改这个类的某一个功能代码时会影响依赖它的多个类。我们需要测试这三个依赖类是否正常工作。这也就是所谓的 “牵一发而动全身”。
另外从图中我们可以看出高内聚、低耦合的代码结构更加简单、清晰相应地可维护性和可读性要好很多。
“迪米特法则”理论描述
迪米特法则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.如何理解“迪米特法则”
不该有直接依赖关系的类之间不要有依赖关系有依赖关系的类之间尽量只依赖必要的接口。迪米特法则是希望减少类之间的耦合让类越独立越好。每个类都应该少了解系统的其他部分。一旦发生变化需要了解这一变化的类就会比较少。
