清洁代码 - 依赖注入

Question

我想知道是否有一个"更清洁"的解决方案来使用依赖注入绑定到具有大量参数的类,因为根据Robert C.Martin的清洁代码,最好不要使用超过3个参数......任何其他解决方案,想法(和例子？)

Answer 1

Dependency Injection != Lot of arguments

您将要使用的参数数量取决于您的个人代码设计，使用 DI，您将专注于实现某些目标所需的依赖项，即使您不根据“对类进行编码”，您当然也至少需要这些依赖项依赖注入/IoC 模式”。如果您有太多争论，您可能必须以某种方式重新考虑您的设计。

如果您有疑问，请考虑可维护性。

“如果我必须改变一些东西，它会在哪里？如果我做出改变，还有多少其他地方会受到改变的影响？”

有可能的解决方法，仅举几例：

1. 将 2 个或更多依赖项包装为一个新依赖项（当您需要多个依赖项时，您将不需要这些依赖项的整个 API，因此您可以将其中的一部分隐藏在新接口后面。）
2. 正如 Spock 所说，您可以创建一个“参数”对象（实现留给您：参数列表或对象结构）。

还取决于您的编程语言，您可能会发现某些解决方案比其他解决方案更有用（选项 1 可能更适合 C++ 等语言，其中每个依赖项都会大大增加编译时间，而选项 2 似乎可能用于 PHP 等语言因为需要用户更少的编码和工作）。

Answer 2

我的看法是……无论您使用构造函数参数还是例程参数，最好避免将大量参数作为参数传递。

甚至 Robert C.Martin 的 Clean Code 也说最好不要使用超过 3 个，这只是一个指南。实际上，这可能会发生变化，因为您可能由于多种原因需要超过此限制。例如，如果您有多个构造函数，有些构造函数确实喜欢很好地列出参数，以便 API 可发现 - 这也意味着参数列表永远不会改变。

但在大多数情况下，情况并非如此，如果参数列表很长，参数可能会更改和重构，并且会变得更加困难。我使用数组或包含对象，因此更改只是该对象。

因此，首选是使用较少的参数（最多 3/4），但如果过度，请创建一个可以传递的对象。虽然这可以满足大多数情况，但有时您可能必须拥有很长的参数列表（IMO）。