【问题标题】:Interfaces without dependency injection [closed]没有依赖注入的接口[关闭]
【发布时间】:2019-05-03 06:42:29
【问题描述】:

自从 DO 和 IOC 变得广为人知并被使用以来,我看到了为许多类使用接口的趋势,即使这些类不是由 D/IOC 解析的服务。就像在经常引用类本身而不是接口时,至少有一个类的接口会更好。如果没有 DI/IOC,使用这样的接口有什么好处。

【问题讨论】:

  • 如果能贴一些代码就更好了。
  • 如果您只有 1 个概念的实现,并且只计划拥有 1 个,那么就没有必要使用接口。如今,大多数 DI 容器都允许类注册和接口注册,因此即使您决定全部进行 IoC,您仍然可以跳过接口。但是,如果您打算用多种方法给这只猫剥皮,您可能需要制作 iCatSkinner,这样它们就可以被视为同一个东西。
  • 不仅对于 DI,而且对于测试来说,使用接口是有意义的。我们为需要模拟的类使用了很多接口。

标签: .net design-patterns dependency-injection


【解决方案1】:

这样的问题并不总是有相同的答案。制作界面有很多好的理由,但也有很多界面是无缘无故制作的。

通常,接口用作参数类型来声明构造函数或方法需要,因为在其参数中需要特定实现的构造函数或方法可以用于更少的上下文。

这是非私有方法和构造函数的一个重要考虑因素,这就是接口的使用如此普遍的原因。它涵盖的用例远不止 DI。

但是,如果您正在创建一个不需要传递给任何此类方法或构造函数的实现类,那么就没有理由制作接口。每个类或接口都应该有一个目的......并且“成为这个类的接口”不是一个有效的目的。

接口的目的是捕获其消费者的需求,而不是其实现。

【讨论】:

    【解决方案2】:

    对我来说,接口首先是解耦代码的方式。是否使用 IOC 并不重要。即使使用具有单个实现的接口也是一件好事。对于应用程序的演进,最好使用我们可以重新实现的接口以满足我们的新需求或我们想要进行的更改。

    这篇文章比我描述得更好我的看法:Decouple your code

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2021-03-24
      • 2017-06-10
      • 2010-12-16
      • 2023-03-23
      • 2012-11-28
      • 2011-12-05
      • 2014-10-06
      相关资源
      最近更新 更多