依赖注入最佳实践和反模式

rip*_*234 31 language-agnostic dependency-injection anti-patterns

我在依赖注入方面相对不熟练,我想学习一些最佳实践和反模式,分别在使用DI时使用和避免.

Sam*_*ham 9

我非常喜欢这篇关于DI的文章,因为它针对的是没有大量DI经验的人,或者甚至不知道它是什么.

https://mtaulty.com/2009/08/10/m_11554/

什么是团结?

It’s a “dependency injection container”.
Run Code Online (Sandbox Code Playgroud)

现在,在这一点上,一群读这篇文章的人会说"是的,我们知道并且我们已经因为A,B,C的原因而使用它,或者我们选择不使用它,原因是X,Y,Z"和我想其他一些人可能会说;

“Huh? What’s a dependency injection container?”
Run Code Online (Sandbox Code Playgroud)

这篇文章适用于后者 - 它并不意味着详尽无遗,但希望它也不是完全无益的:-)


Ale*_*x B 1

我发现,当我看到违反德米特定律的行为时,就暗示我可能需要依赖注入。

例如:

void doit()
{
    i += object.anotherobject.addvalue; //violation of Law of Demeter
}
Run Code Online (Sandbox Code Playgroud)

有时暗示我可能想要依赖注入anotherobject

  • 这是有一定道理的,尽管有点飞跃,而且还不完整。如果你发现违反了迪米特法则,你就找到了选择抽象的机会。任何时候进行抽象,您都有机会选择注入依赖项,而不是自己创建依赖项。所以这是一个指标,但仅仅是一个指标。可能还有更多的抽象机会,并且在实施成本高于您可能获得的成本的地方避免 DI 可能会很有用。尽管如此,还是+1。 (2认同)