oop - 什么时候紧耦合是必要的还是一件好事？

Question

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

但是，假设某个特定的软件公司(我不工作)有一些设计有问题的与某些硬件交互的大型软件。模块(我从未参与过)是如此紧密地耦合，并且函数调用深入到 20 多个级别来管理状态。类边界从来没有明确定义，用例也没有考虑过。一个好的软件开发人员(不是我)会提出这些问题，但只会被更高级的开发人员拒绝，因为开发实践(如 SOLID 或 TDD)并不真正适用，因为该软件多年来一直使用“传统”方法，而改变为时已晚。客户(我不知道他们是谁)最大的提示是产品的质量。

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

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

Answer 1

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

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

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

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

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

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