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

本文关键字：注入 接口 是否 依赖 | 更新日期: 2023-09-27 18:19:48

我听到一位正在工作的开发人员提到DI的全部意义应该是使用接口。作为经验法则，具体类的使用应该保持在最低限度。'u2028如果我们配置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处于同一级别，并且由于此处的Single Responsibility Principlecenter链接描述，它被分离了。提取这样的界面对我来说还有意义吗

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

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

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

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

http://en.wikipedia.org/wiki/SOLID_（面向对象设计）

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

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

  • 测试变得更加容易和安全，因为您不会把真正的实现拖在后面
  • 应用程序的各个部分可以单独部署，因为使用者只依赖于抽象，而不依赖于实现
  • 在处理接口时，通过使用decorator模式（或使用其他AOP技术，如拦截）来附加行为要容易得多
相关文章：