干净的代码 - 依赖注入

我想知道是否有一个“更清洁”的解决方案，使用依赖注入绑定到有很多参数的类，因为根据Robert C.Martin的Clean Code，最好不要使用超过3个参数...任何其他的解决方案，想法（和例子？）干净的代码 - 依赖注入

2014-09-23 RubenHerman

当一个类有很多依赖项时，你是否特别指构造函数注入？ – David 2014-09-23 13:05:25

可能不会回答你的问题，但我认为将数组作为单个参数传递是非常干净的，实际上它包含许多不同的信息。我已经看到这在JavaScript中做了很多，jQuery是一个典型的例子。不是迪，但它确实清理了很多争论的问题。 – srayner 2014-09-23 13:09:03

如果你似乎有很多的依赖关系，那么我会问你的设计是否紧密耦合。 – srayner 2014-09-23 13:10:58

我承担.. 不管你是否使用构造器参数或程序参数，最好避免很多作为参数传递的参数。

即使罗伯特C.马丁的洁净代码说，最好不要超过3，这只是一个指导方针。实际上，这可能会改变，因为您可能需要超出此限制的原因数量。例如，如果您有多个构造函数，则有些参数会很好地列出，以便API可以被发现 - 这也意味着参数列表永远不会改变。

但是，在大多数情况下，参数可能会改变和重新分解并且如果您有很长的参数列表会变得更困难，情况并非如此。我使用数组或包含对象，所以更改将只是该对象。

所以首选是使用较少的参数3/4 max，但如果你过度，创建一个可以传递的对象。虽然这会满足大多数情况，但有时您可能必须要有长参数列表IMO。

来源

2014-09-24 07:48:23 Spock

是否有可能提供一个小例子如何将其设置为一个对象？ – RubenHerman 2014-10-01 06:48:03

我现在所做的是：我创建了一个抽象类，并在该构造函数中使用了Kernel.Get <...>，所以我不必在构造函数中传递它们。这是更好的解决方案吗？我的其他类来自抽象类 – RubenHerman 2014-10-01 08:39:47

在这种情况下，您需要上下文绑定。通常IoC/DI框架假设1个接口= 1个具体类。大多数框架允许多态绑定，但是你不需要它，因为你可以使用变通解决方案。当你需要同时使用上下文绑定的多个实现可能会导致比寻找替代解决方案更多的bug。（通过Polymorphic我的意思是不同的实现共存于相同的接口） – GameDeveloper 2014-10-05 19:05:28

Dependency Injection != Lot of arguments

，你要使用的参数数目取决于你的个人代码设计，用DI你专注于你需要实现的东西的依赖，当然你需要至少那些即使你不依赖用“依赖注入/ IoC模式”来编写类。如果你有太多的论点，你可能不得不重新考虑你的设计。

如果你怀疑在维护方面想。

“如果我必须改变某些东西，它会在哪里？如果我做了这样的改变，那么改变会触及多少其他地方？”

有可能的解决方法，只是说几个：

裹2个或更多的依赖作为一种新的依赖（机会是很高，当你需要多依赖的你将不再需要这些依赖的整个API和因此你可以将它的一部分隐藏在一个新的界面之后..）
由于Spock说你可以创建一个“参数”对象（实现留给你：参数列表或对象结构）。

也取决于你的编程语言，你可能会发现更多有用的某些解决方案，而不是其他人（选项1可能更适合用语言，如C++每个依赖会增加大量的编译时间，而选项2似乎有可能与PHP等语言一起使用，因为用户需要更少的编码和努力）。

来源

2014-09-24 14:14:54 GameDeveloper

干净的代码 - 依赖注入

回答

相关问题