我想知道是否有更清洁的＆＃34;使用依赖注入绑定到具有大量参数的类的解决方案，因为根据Robert C.Martin的清洁代码，最好不要使用超过3个参数......任何其他解决方案，想法（和例子？）
答案 0 :(得分：4)
我的看法...... 无论您是使用构造函数参数还是常规参数，最好避免将许多参数作为参数传递。
即使是Robert C.Martin的清洁代码，也说最好不要超过3，这只是一个指导方针。实际上，由于原因可能需要超出此限制，因此可能会发生变化。例如，如果你有多个构造函数，有些确实很好地列出了参数，所以API可被发现 - 这也意味着参数列表永远不会改变。
但在大多数情况下情况并非如此，如果你有长参数列表，参数可能会改变并重新分解并变得更难。我使用数组或包含对象，因此更改只是该对象。
所以首选使用较少的参数3/4 max，但是如果你超越，则创建一个可以传递的对象。虽然这可以满足大多数情况，但有时您可能必须拥有长参数列表IMO。
答案 1 :(得分：4)
Dependency Injection != Lot of arguments
你要使用的参数数量取决于你的个人代码设计，DI你专注于你需要实现某些东西的依赖关系，你当然至少需要那些依赖关系，即使你没有编写一个类“依赖注入/ IoC模式”的术语。如果你有太多的论点，你可能不得不重新考虑你的设计。
如果您有疑问，请考虑维护性。
“如果我必须改变一些东西，它会在哪里改变？如果我做了那些改变，改变会触及多少其他地方？”
有一些可行的解决方法，仅举几例：
根据您的编程语言，您可能会发现某些解决方案比其他解决方案更有用（选项1可能更适合C ++等语言，其中每个依赖项可能会大量增加编译时间，而选项2似乎可能与像PHP这样的语言，因为用户需要更少的编码和工作量。）