3

我听说一位开发人员在工作中提到 DI 的重点应该是使用接口。作为经验法则，应将具体类的使用保持在最低限度。如果我们将 DI 配置为使用特定类的实例不只少数，那么它就是代码异味。

现在我不确定我是否可以将此作为一个空白规则。我一直认为 DI 的一个重要原因是易于测试。

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

编辑：假设我有一个类 BookingMapper，它将 Booking 对象从一个域映射到另一个域。假设它有一个 Hotel 对象，它需要作为映射 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(){...}
}

在这样的用例中，我已经知道我的 Booking Mapper 组件在任何时候都将与我的 HotelMapper 处于同一级别，并且由于单一责任原则在此处输入链接描述而将其分离出来。提取出像这样的界面对我来说仍然有意义吗

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

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

4

2 回答 2

1

看看SOLID原理，然后再看看它们。您会看到 DI 和基于接口的设计是 OOP 的重要组成部分。它认为你会同意你的同事说得很有道理。是的，你是对的，DI 会让你的测试更容易/更好。

http://en.wikipedia.org/wiki/SOLID_(面向对象设计)

于 2013-06-25T18:24:53.973 回答
1

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

然而，当依赖于抽象而不是实现时有很多优点：

  • 测试变得更加容易和安全，因为您没有拖后真正的实现。
  • 您的应用程序的各个部分可以单独部署，因为消费者只依赖于抽象，而不是实现。
  • 在处理接口时，使用装饰器模式（或使用其他AOP技术，如拦截）附加行为要容易得多。
于 2013-06-25T19:33:28.413 回答