“太多的依赖”代码味道？

Question

作为一般规则，我喜欢使用基于构造函数的依赖注入，但最近我正在研究一个依赖于其他4个类的类。因为很长的参数列表很难阅读，所以我用4个setter替换了4个参数的构造函数。

当我向一位同事提到这件事时，他认为这本身就是一种代码味道。他建议我“分手”这堂课。

这个班本身已经比较小了，它恰好使用多个协作者来完成大部分工作。它由一个简短的（~12行，包括空白）方法组成，可以调用4个协作者。你同意还是不同意这种说法：这是一种代码味道？是否有一些客观的度量可用于确定多少依赖关系“太多”？这与圈复杂度，内聚力，耦合度等指标有什么关系？

Answer 1

就你刚说的问题而言，是的。但是它更复杂一些，如果你在6个月后出现这个代码，你可以在阅读代码之后的2-3分钟内完成它吗？它是否需要您查看代码库的其他部分才能理解它？修改协作者是否需要修改此类？你能用2-4个句子向另一位工程师（尤其是新工程师）解释这门课程吗？所有这些都有助于决定这一点。

我想说的是，这里有无形的东西，在决定之前也应该考虑。这是一个经验问题，并且知道什么时候不知道如何应用普遍认可的规则是很重要的。