松耦合

在计算和系统设计中，松耦合系统是其中之一

• 其中组件之间的关联较弱（具有可破坏的关系），因此一个组件的更改对另一个组件的存在或性能的影响最小。
• 其中每个组件对其他单独组件的定义知之甚少或一无所知。 子领域包括类、接口、数据和服务的耦合。 松紧合与紧耦合相反。

松散耦合系统中的组件可以替换为提供相同服务的替代实现。 松散耦合系统中的组件较少受限于相同的平台、语言、操作系统或构建环境。

如果系统及时解耦，则很难同时提供事务完整性； 需要额外的协调协议。 跨不同系统的数据复制提供了松耦合（可用性），但在保持一致性（数据同步）方面产生了问题。

更广泛的分布式系统设计中的松弛结合是通过使用事务、面向消息的中间件提供的队列和互操作性标准来实现的。

促进松散耦合的四种自治类型是：引用自治、时间自治、格式自治和平台自治。

松懈合是面向服务架构中的架构原则和设计目标； 十一种形式的松耦合及其对应的紧耦合列于：

• 通过调解员进行物理连接，
• 异步沟通方式，
• 仅在数据模型中的简单通用类型，
• 弱类型系统，
• 以数据为中心且独立的消息，
• 流程逻辑的分布式控制，
• 动态绑定（服务消费者和提供者），
• 平xxx立性，
• 业务级薪酬而不是系统级交易，
• 在不同时间部署，
• 版本控制中的隐式升级。

企业服务总线（ESB）中间件被发明来实现多维度的松耦合； 然而，过度设计和错误定位的 ESB 也会产生相反的效果，并产生不希望的紧密耦合和中心架构热点。

事件驱动架构也旨在促进松散耦合。

可以通过以标准格式（例如 XML 或 JSON）发布数据来增强接口的松紧结合。

可以通过在参数中使用标准数据类型来增强程序组件之间的松紧结合。 传递自定义数据类型或对象需要两个组件都了解自定义数据定义。

可以通过减少传递到服务中的关键数据的信息来增强服务的集成。 例如，当仅传递客户标识符并在服务中获取客户地址时，发送信件的服务的可重用性最高。 这解耦了服务，因为不需要按特定顺序调用服务（例如 GetCustomerAddress、SendLetter）。

耦合是指一个组件对另一个组件的直接了解程度。 计算中的松紧合被解释为封装与非封装。

当依赖类包含直接指向提供所需行为的具体类的指针时，就会出现紧耦合的例子。 如果不更改依赖类，则无法替换依赖项或更改其签名。 当依赖类仅包含一个指向接口的指针时，就会发生松绑合，然后可以由一个或多个具体类实现该接口。 依赖类的依赖是接口指定的契约； 实现类必须提供的定义的方法和/或属性列表。 因此，任何实现该接口的类都可以满足依赖类的依赖性，而无需更改该类。

这允许软件设计的可扩展性； 可以编写一个实现接口的新类来替换某些或所有情况下的当前依赖项，而无需更改依赖类； 新旧班级可以自由互换。 强耦合不允许这样做。

这是一个 UML 图，说明了依赖类和一组具体类之间松散耦合的示例，这些具体类提供了所需的行为：

为了进行比较，此图说明了依赖类和提供者之间具有强耦合的替代设计：

将函数作为核心模块（请参阅函数式编程）或将函数作为对象的概念的计算机编程语言提供了松散耦合编程的绝佳示例。 函数式语言具有 Continuations、Closure 或生成器的模式。