第二部分:理论八
第二部分:理论八
理论八
何为“高内聚、松耦合”?
- “高内聚、松耦合”是一个非常重要的设计思想,能够有效地提高代码的可读性和可维护性,缩小功能改动导致的代码改动范围。
- “高内聚”用来指导类本身的设计,“松耦合”用来指导类与类之间依赖关系的设计。
那到底什么是“高内聚”呢?
- 所谓高内聚,就是指相近的功能应该放到同一个类中,不相近的功能不要放到同一个类中。
- 相近的功能往往会被同时修改,放到同一个类中,修改会比较集中,代码容易维护。
我们再来看一下,什么是“松耦合”?
- 所谓松耦合是说,在代码中,类与类之间的依赖关系简单清晰。
- 即使两个类有依赖关系,一个类的代码改动不会或者很少导致依赖类的代码改动。
最后,我们来看一下,“内聚”和“耦合”之间的关系。
- 文中举例,通过两张图来对比。
- 左图中,类的粒度比较小,每个类的职责都比较单一。相近的功能都放到了一个类中,不相近的功能被分割到了多个类中。这样类更加独立,代码的内聚性更好。因为职责单一,所以每个类被依赖的类就会比较少,代码低耦合。一个类的修改,只会影响到一个依赖类的代码改动。我们只需要测试这一个依赖类是否还能正常工作就行了。
- 右图中,类粒度比较大,低内聚,功能大而全,不相近的功能放到了一个类中。这就导致很多其他类都依赖这个类。当我们修改这个类的某一个功能代码的时候,会影响依赖它的多个类。我们需要测试这三个依赖类,是否还能正常工作。这也就是所谓的“牵一发而动全身”。
- 另外,高内聚、低耦合的代码结构更加简单、清晰,相应地,在可维护性和可读性上确实要好很多。
“迪米特法则”理论描述
- 迪米特法则的英文翻译是: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) { //... }
}