从我对 OO 设计/模式/原则的所有阅读和研究中，我发现普遍的共识是松散耦合（和高内聚）几乎总是更好的设计。从我过去的软件项目经验来看，我完全同意。
但是，假设某个特定的软件公司（我不工作）有一些设计有问题的与某些硬件交互的大型软件。模块（我从未参与过）是如此紧密地耦合，并且函数调用深入到 20 多个级别来管理状态。类边界从来没有明确定义，用例也没有考虑过。一个好的软件开发人员（不是我）会提出这些问题，但只会被更高级的开发人员拒绝，因为开发实践（如 SOLID 或 TDD）并不真正适用，因为该软件多年来一直使用“传统”方法，而改变为时已晚。客户（我不知道他们是谁）最大的抱怨是产品的质量。
由于上述不切实际的场景（我从来没有分开过），我考虑过是否存在首选甚至需要紧密耦合的情况？什么情况下开发人员需要跨越模块边界并共享状态并增加依赖性并降低可测试性？有哪些系统如此复杂以至于需要这样做的例子？我自己想不出一个好的案例，所以我希望一些更有经验的工匠能帮助我。
谢谢。再说一次，我不知道这家公司。