本文介绍了软件架构中的九种耦合形式，通过了解不同的层次的耦合，架构师和开发者在设计时就可以做出不同选择，从而实现针对性的设计。原文: 9 Forms of Coupling in Software Architecture[1]
没有任何软件系统可以摆脱依赖关系，或者保证即使依赖组件发生变化也不会产生任何影响。软件架构师总是要处理相互连接的组件之间的依赖程度，并尽量减少甚至消除这种影响。如果软件组件 A 在如下情况下需要软件组件 B，那么软件组件 A 就依赖于软件组件 B：
运行时编译 安装 测试 正常运行
耦合是任意架构构件之间的依赖程度。
在不同抽象层次上，存在着不同类型的耦合。耦合不仅发生在源代码层面，还发生在基础架构以及其他方面。软件架构师需要了解这些类型，以便在设计这些组件时做出正确决定。我们将根据 ISAQB 软件架构认证课程来了解这些耦合类型。
通过使用/委托耦合.
这种耦合是经典耦合之一。基本上，如果类 A 调用类 B 的公有变量，它们就会通过使用/委托耦合在一起。最好的解决方法是将这些公有变量私有化，并通过 getter 调用它们。
通过组合耦合
在组合关系中，正如面向对象编程中所定义的，类 A 包含类 B。在某些情况下，类 B 可以是类 A 的内部部分，并不独立存在。因此，这些类通过组合关系耦合在一起。
通过构建耦合
这类耦合出现在工厂、抽象工厂等构建设计模式中。在这些设计模式中，类 A 或 B 的构建被委托给工厂类。也就是说，类 A 或 B 是通过构建与工厂类耦合的。
通过继承耦合
子类继承超类的属性和方法的一种依赖关系。通过继承产生的耦合非常严格，因为父类做什么，子类就做什么。
通过信息或事件耦合
消息传递中间件和事件存储广泛用于组件之间的松散耦合。在消息传递中，通信是异步的，发送方的请求被发送到消息队列中，接收方从队列中获取请求。发送方可能知道也可能不知道哪个接收方收到了请求，也不会立即回复。在事件处理中，想法与消息传递类似，但这里的状态变化是按时间顺序传递给监听者的。由于这种通信也是异步的，耦合非常松散，因此非常受欢迎。
时序耦合
在这种耦合中，如果 A 组件在 B 组件提供某些输出之前无法执行其工作，那么 A 组件就会暂时依赖于 B 组件。在这种耦合中，组件 A 和组件 B 不需要使用相同的编程语言或基础设施。例如，要在电商网站中购买一些商品，首先需要选择并将商品添加到购物车中。
通过数据类型耦合
根据业务需要，开发者会创建一些自定义数据类型以供进一步使用。例如，在 JPA 中创建的 UserEntity 与数据库中的 User 表相对应。因此，UserEntity 将成为软件系统中的核心数据类型，在任何需要处理用户数据的地方都可以使用。如果 UserEntity 有微小的变化，所有依赖类都会受到影响。这就是通过数据类型实现的耦合。
通过数据耦合
当组件 A 在数据库、配置文件或环境变量中持久化保存信息，而组件 B 也与之通信时，就会出现数据耦合。如果一个组件的变化通过这些耦合数据影响到另一个组件，那么很可能需要松开这些耦合。
通过硬件耦合
设想有一个物理硬件或服务器，组件 A 在内存位置写入了一些内容，组件 B 在读取这些内容时也会受到影响。这种耦合是通过硬件实现的，经常发生在底层编程中。
你好，我是俞凡，在Motorola做过研发，现在在Mavenir做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。为了方便大家以后能第一时间看到文章，请朋友们关注公众号"DeepNoMind"，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的支持和动力，激励我持续写下去，和大家共同成长进步！
9 Forms of Coupling in Software Architecture: https://azeynalli1990.medium.com/9-forms-of-coupling-in-software-architecture-4d5cf2b3e99e
