在构造函数中使用注入的实现 [英] use injected implementation in constructor

问题描述

很抱歉，标题不明确，但我不确定该如何措辞。

Sorry about the ambiguous title, but I wasn't sure how to phrase it.

我正在寻找有关以下内容是否会导致注入对象的不良使用的任何想法。我在应用程序中设置了一个IOC容器（我正在使用Unity，但我认为这并不重要）。我想知道这是不好的做法，还是从注入接口实现中在构造函数中设置变量，而没有将注入实现设置为私有变量，有什么收获。

I am looking for any thoughts on whether the following would be a poor usage of an injected object. I have an IOC container set up in my application (I am using Unity, but I don't think that really matters for this). I was wondering if it is bad practice or if there is any catch to setting a variable in the constructor from the injected interface implementation without ever setting the injected implementation to a private variable.

在下面的示例中，我的IOC容器将 injectedClass 注入到构造函数中。通常，我会将 injectedClass 设置为等于 IInjectedClass 的私有实例，但是由于我只打算使用它来设置单个变量，我只是在构造函数中设置了变量，然后就忽略了注入的项。

In the example below, injectedClass is injected into the constructor by my IOC container. Typically, I would set injectedClass equal to a private instance of IInjectedClass, but since I am only going to use it to set that single variable, I am just setting the variable it in the constructor and then forgetting about the injected item.

public class SomeClass
{
    private string _someVariable;

    public SomeClass(IInjectedClass injectedClass)
    {
         _someVariable = injectedClass.GetSomeString();
    }

    public void SomeMethod()
    {
         Console.WriteLine(_someVariable);
    }

}

是否存在上述原因代码会是一个坏习惯吗？还是反对它的唯一论点，如果我想再次使用injectionedClass，它将不可用？

Is there any reason that the above code would be a bad practice? Or is the only argument against it that if I wanted to use the injectedClass again, it would not be available?

感谢任何想法

推荐答案

这样做有几个问题。一个是它违反了尼古拉·马洛维奇（Nikola Malovic）的 IoC的第四定律。

There are several problems with doing this. One is that it violates Nikola Malovic's 4th law of IoC.

在有关堆栈溢出的另一个答案，我概述了此规则的各种动机。

In another answer here on Stack Overflow, I've outlined the various motivations for this rule.

在这种特殊情况下，还有一个额外的问题，它使您的班级难以推理。当您将类看作一个黑盒（这是所有封装所涉及的内容）时，您将看到：

In this particular case, there's the additional problem that it makes your class harder to reason about. When you look at the class as a black box (which is what all encapsulation is about), this is what you see:

public class SomeClass
{
    public SomeClass(IInjectedClass injectedClass)

    public void SomeMethod()    
}

看起来 就像 SomeClass 需要 IInjectedClass ，但事实证明，它实际上只需要一个字符串。这使使用起来更加困难，因为您必须提供一个完整的 IInjectedClass 实例，而您所能拥有的只是一个字符串。您可以说这违反了邮编。

It looks as though SomeClass requires IInjectedClass, but it turns out that it really only needs a string. This makes it more difficult to use, because you have to supply a complete IInjectedClass instance, when all you could have gotten away with was a string. You could say that this violates Postel's Law.

一个更好的选择是诚实对待依赖关系，并以原始依赖项：

A better alternative is to be honest about the dependencies and request the string as a Primitive Dependency:

public class SomeClass
{
    private string _someVariable;

    public SomeClass(string someVariable)
    {
         _someVariable = someVariable;
    }

    public void SomeMethod()
    {
         Console.WriteLine(_someVariable);
    }

}

这篇关于在构造函数中使用注入的实现的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！