Question

我听说其中一位开发人员提到DI的重点应该是接口的使用。具体类的使用应该作为拇指规则保持最小。如果我们将DI配置为使用特定类，那么它的代码就会出现问题。

现在我不确定我是否可以将此作为一个空白点。 DI的一个重要原因，我一直觉得是测试的简易性。

使用接口可能有其他原因，在具体类中作为我的代码中的依赖项（比如插入其他逻辑实现的容易程度等），但是我看不出依赖注入的使用是如何暗示的这一点。

编辑：假设我有一个类BookingMapper，它将Booking对象从一个域映射到另一个域。假设它有一个酒店对象，它需要映射作为映射预订的一部分。它使用HotelMapper类来做同样的事情。

public class Booking
{
    ...
    Hotel Hotel;
}

public class BookingMapper
{
    private readonly HotelMapper hotelMapper;
    public BookingMapper(HotelMapper hotelMapper)
     {
      this.hotelMapper = hotelMapper;
     }
    Map(){...}
}
public class HotelMapper
{
     Map(){...}
}

在这种使用案例中，我已经知道，我的预订映射器组件在任何时候都与我的HotelMapper处于同一级别，并且由于单一责任原则enter link description here而被分离出来。我是否仍然有必要提取出像

这样的界面

public interface IHotelMapper
{
void Map();
}
public class BookingMapper
    {
        private readonly IHotelMapper hotelMapper;
        public BookingMapper(IHotelMapper hotelMapper)
         {
          this.hotelMapper = hotelMapper;
         }
        Map(){...}
    }

然后使用它作为BookingMapper中的依赖项而不是直接使用HotelMapper？

Answer 1

查看SOLID原则，然后再次查看它们。你会发现DI和基于接口的设计是OOP的重要组成部分。它认为你会同意你的同事很有意义。是的，你是对的，DI会让你更容易/更好地进行测试。

http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)

Answer 2

依赖注入是一种模式，它本身可以完全使用而无需定义接口。您可以让消费者依赖其他具体课程。通过将这些类的重要方法设为虚拟，您甚至可以从中导出虚假实现以用于测试目的。

depending on abstractions instead of implementations：

有许多优点

测试变得更加容易和安全，因为您不会拖延真正的实现。
您的应用程序的某些部分可以单独部署，因为消费者只依赖于抽象，而不是实现。
使用decorator pattern（或使用AOP等其他interception技术）添加行为在处理界面时要容易得多。

使用依赖注入是否需要使用接口而不是具体类？

2 个答案: