依赖注入和显式接口实现

本文关键字：显式接口实现 注入 依赖 | 更新日期: 2023-09-27 18:05:10

在依赖注入方面显式实现接口是否有好处?

据我所知，接口既可以显式实现，也可以隐式实现:

interface IFoo
{
    void Bar();
}
//implicit implementation
class Foo1 : IFoo
{
    public void Bar(){}
}
//explicit implementation
class Foo2 : IFoo
{
    void IFoo.Bar(){}
}

现在显式实现只能通过调用接口方法来调用，而隐式实现可以直接在类的实例上调用:

class Baz
{
    void Ba()
    {
        Foo1 foo1 = new Foo1();
        foo1.Bar();
        Foo2 foo2 = new Foo2();
        foo2.Bar();    //syntax error
        IFoo foo2_explicit = new Foo2();
        foo2_explicit.Bar();
    }
}
因此，使用显式接口实现，不能意外地调用具体类上的方法，但必须调用接口方法。这是否阻止了紧密耦合代码，这是DI的一个目的，还是我在这里找错了方向?毕竟，不能偶然地编写一个构造函数或方法来注入一个具体类，而不是一个接口: 
class Baz
{
    void Ba(Foo2 foo)
    {
        foo.Bar(); //syntax error
    }
    void Bb(IFoo foo)
    {
        foo.Bar();
    }
}

依赖注入和显式接口实现

通常，依赖注入的目的是解耦，您可以通过将抽象注入其客户端来实现:

public class Baz
{
    private readonly IFoo foo;
    public Baz(IFoo foo)
    {
        this.foo = foo;
    }
    // Members using this.foo go here...
}

这确保了Baz依赖于IFoo，并且与任何具体实现解耦。

具体类是否显式或隐式实现IFoo没有区别。

偶尔，一个类可能有具体依赖，但这不是特别正常;当它发生时，具体的依赖是具体的，所以通常根本不会实现接口。在这种情况下，显式接口实现与隐式接口实现无关。

如果你的类在容器中，那么你使用接口。所以，没有好处。

但是，如果你直接使用你的类(例如在测试中)，你必须强制转换来访问方法，这是不方便的。

Total: 0在容器中使用class而不用于测试时的优势

在我看来，通常应该始终保持对类型"刚好"可以使用的对象的引用。考虑下面的例子:

public interface IDo
{
    void Do();
}
public interface IWatch
{
    void Watch();
}
public class Foo : IDo, IWatch
{
    public void Dummy() { }
    public void Watch() { }
    public void Do() { }
}

然后:

//I only want to use Do()
IDo aFoo = new Foo();
//I only want to use Watch()
IWatch bFoo = new Foo();
//I want to use stuff from Foo and optionally stuff from IDo or IWatch
Foo cFoo = new Foo();

当使用像MEF或Unity这样的依赖注入容器时，你应该使用一个接口将对象导出到容器中，并使用相同的接口类型导入它。

遵循这些模式，我并没有看到使用显式接口实现有什么好处。(这也使得在文本编辑器上方的标准Visual Studio组合框中定位实现方法变得更加困难)

相关文章：