![现代C++软件架构:方法与实践](https://wfqqreader-1252317822.image.myqcloud.com/cover/127/48894127/b_48894127.jpg)
上QQ阅读APP看本书,新人免费读10天
设备和账号都新为新人
1.8.1 耦合
耦合衡量的是一个软件单元对其他单元的依赖程度。耦合度高的单元依赖许多其他单元,耦合度越低越好。
例如,如果一个类依赖于另一个类的私有成员,这就意味着它们是紧密耦合的。第二个类的改动可能意味着第一个类也需要改动,所以这不是一个理想的情况。
为了削弱前面场景中的耦合,我们可以考虑为成员函数添加参数,而不是直接访问其他类的私有成员。
紧耦合类的另一个例子是1.7.5节中的Project类和开发人员类的第一个实现。我们来看如果再添加另一种开发人员类型会发生什么:
![](https://epubservercos.yuewen.com/574F91/28606613407439306/epubprivate/OEBPS/Images/32_01.jpg?sign=1739015442-OEgUwt2WoYZIFWZ6bG1ou4a18Z3P8XHR-0-30b31b34936dba8e4278d6b30faf1121)
看起来不仅仅是添加MiddlewareDeveloper类,我们还必须修改Project类的公共接口。这意味着它们是紧密耦合的,Project类的实现实际上破坏了开放封闭原则(OCP)。为了进行比较,现在我们来看如何将相同的改动应用在使用了依赖倒置的实现中:
![](https://epubservercos.yuewen.com/574F91/28606613407439306/epubprivate/OEBPS/Images/32_02.jpg?sign=1739015442-aRrbBh0erfy49YeZZRjhdppFBZZ2s5Rr-0-123fb728f349259375c08a072f892cd2)
![](https://epubservercos.yuewen.com/574F91/28606613407439306/epubprivate/OEBPS/Images/33_01.jpg?sign=1739015442-0bacz1aMz6G2u2uTcZYuEUMjhq2uyk6A-0-4b6562cf0a9fdef907eab28b06c07dc5)
此时,不需要对Project类进行任何更改,所以现在这些类是松耦合的。我们所需要做的就是添加MiddlewareDeveloper类。以这种方式构建代码可以实现更少的重建、更快的开发和更容易的测试,代码更少,也更容易维护。要使用新类,只需要修改调用代码:
![](https://epubservercos.yuewen.com/574F91/28606613407439306/epubprivate/OEBPS/Images/33_02.jpg?sign=1739015442-taKiHLdh6ZXmDYcECnqibTtemILo0B4C-0-2ad2334ab725a14f1c766429a63d035a)
上面展示了类级别的耦合。在更大的范围内,例如在两个服务之间,可以通过引入消息队列等技术来实现低耦合。这样,这些服务就不会直接相互依赖了,而是只依赖于消息格式。微服务架构一个常见的错误是让多个服务使用同一个数据库,这会导致这些服务之间相互耦合,因为我们无法在不影响使用它的其他微服务的情况下随意地修改数据库模式(database schema)。
下面我们讨论下内聚。