「太多的依賴」代碼味道？

Question

作爲一般規則，我喜歡使用基於構造函數的依賴注入，但最近我正在研究一個依賴於其他4個類的類。因爲很長的參數列表很難閱讀，所以我用4個setter替換了4個參數的構造函數。

當我向一位同事提到這件事時，他認爲這本身就是一種代碼味道。他建議我「分手」這堂課。

這個班本身已經比較小了，它恰好使用多個協作者來完成大部分工作。它由一個簡短的（~12行，包括空白）方法組成，可以調用4個協作者。你同意還是不同意這種說法：這是一種代碼味道？是否有一些客觀的度量可用於確定多少依賴關係「太多」？這與圈複雜度，內聚力，耦合度等指標有什麼關係？

Answer 1

就你剛說的問題而言，是的。但是它更復雜一些，如果你在6個月後出現這個代碼，你可以在閱讀代碼之後的2-3分鐘內完成它嗎？它是否需要您查看代碼庫的其他部分才能理解它？修改協作者是否需要修改此類？你能用2-4個句子向另一位工程師（尤其是新工程師）解釋這門課程嗎？所有這些都有助於決定這一點。

我想說的是，這裏有無形的東西，在決定之前也應該考慮。這是一個經驗問題，並且知道什麼時候不知道如何應用普遍認可的規則是很重要的。