什么时候紧耦合是必不可少的还是一件好事？

Question

从我对 OO 设计/模式/原则的所有阅读和研究中，我发现普遍的共识是松耦合（和高内聚）几乎总是更好的设计。我完全同意从我过去的软件项目经验中发言。

但是，假设某个特定的软件公司（我不在其中工作）有一些设计有问题的大型软件，可以与某些硬件进行交互。这些模块（我从未研究过）是如此紧密耦合，并且函数调用可以深入 20 多个级别来管理状态。类边界从来没有明确定义，用例也没有考虑清楚。一个优秀的软件开发人员（不是我）会提出这些问题，但只会被更高级的开发人员拒绝，因为开发实践（如 SOLID 或 TDD）并不真正适用，因为该软件已经使用“传统”方法运行多年，再改变也晚了。客户（我不知道他们是谁）最大的抱怨是产品质量。

由于上述不切实际的场景（我从来没有分开过），我想过是否存在首选甚至需要紧耦合的情况？什么情况下开发人员需要跨越模块边界并共享状态并增加依赖性并降低可测试性？有哪些系统如此复杂以至于需要这样做？我自己想不出一个好的案例，所以我希望一些更有经验的工匠可以帮助我。

谢谢。再说一遍，我不知道这家公司。

Answer 1

紧密耦合的架构围绕单个事实点集成企业应用程序，该事实点通常是单个支持空间的 RDBMS。链接的应用程序类型包括工程设计 (CAD)、设施记录管理 (GIS)、资产管理、工作流程、ERP、CRM、停电管理和其他企业应用程序。

紧密耦合架构的一个主要优点是，它能够快速有效地处理大量数据，提供单点事实而不是多个通常是冗余的数据源，并支持整个组织对数据的开放访问。

紧密耦合的架构依赖于 SQL、ODBC、JDBC 和 OLEDB、SQL/MM 等标准以及 OGC 的 SQL 简单功能规范，在整个组织中提供对数据（包括地理空间数据）的开放且安全的访问。

松耦合的 Web 服务需要大量的冗余，这与客户端和服务之间的紧密耦合不同，后者可以最大限度地减少冗余。

异步松散耦合 Web 服务的一个问题是，对于某些业务功能，它可能会超出消息队列服务器或系统的资源容量。

可以使松耦合的Web服务切换到紧耦合模式，以避免稀缺资源的系统过载。