2

我正在启动一个我想快速构建的应用程序，稍后将由 20 多个开发人员开发。

在有多个开发人员的环境中了解您对 DI 的了解后，您是否会使用 DI 来开发您想要相对快速构建的新应用程序？

对我来说，现在使用 DI 的成本将是编写和生成的代码行，而不是不为每个对象使用接口。最后，我希望 DI 不会因为反射而成为性能问题。

4

4 回答 4

2

DI 基本上与框架无关。例如，如果您只是将依赖项添加为 constrictor 的参数，那么您就是在执行 DI。实际上，您甚至不需要创建接口（尽管这将有助于测试。稍后介绍接口是对 Java 等语言的简单重构）。DI 只是从类的用户那里移除了创建的责任。

在我看来，最大的代价就是改变主意。学会思考DI。好处包括更容易测试。关注点分离等等。

于 2011-11-12T23:11:11.130 回答
1

简单地说，没有依赖注入做面向对象的开发是不好的。很坏。在我看来，依赖注入是众所周知的 OO 开发的根源：关注点分离、独立组件之间的松散耦合、分层编码，所有这些都是使用 DI 完成的。而且，它使测试变得异常容易，并允许使用 TDD、模拟 (BDD) 等技术。

正如释迦牟尼在他的回答中所说，DI与您使用的框架无关。Spring 没有发明 DI，它只是提出了实现它的解决方案。因此，如果您最初的问题是“我们应该使用 Spring”，那么我会说这是个人品味的问题。如果你自己做，你可以得到完全相同的结果。我曾在有或没有容器（Spring、pico 等）的项目中工作过，它们都有其优点和缺点。不过，我个人的偏好是不使用其中的任何一个并自己管理您的 DI。

这是 DI：

// constructor
public MyClass(MyDependencyInterface injected) {
    this.dependency = injected;
}

或者那个：

// setter injection
public void setDependency(MyDependencyInterface injected) {
    this.dependency = injected;
}

最后，我希望 DI 不会因为反射而成为性能问题。

不知道你是什么意思。DI 不需要反射。

于 2011-11-12T23:22:25.197 回答
0

我肯定会提倡 DI，尤其是在有很多开发人员的情况下。

这允许每个开发人员编写和测试他们自己的代码，而无需依赖在他们控制之外开发的注入组件。

它还可以促进接口定义，因此每个人都知道哪些功能可以从哪些组件中获得。

于 2011-11-12T23:17:00.953 回答
0

Java 的基本问题是，当您在 A 类中执行 a 时，new B()这意味着 A 类在字节码级别与 B 类非常紧密地绑定。

这通常是一件好事，因为这意味着生成的应用程序变得非常坚固，因为所有“砖块”都很好地“粘合在一起”。

然而，你经常需要推迟一些设计问题来部署时间（有时甚至是运行时），而在 Java 中处理这个问题的方法传统上是委托给一个工厂，它甚至可能反过来委托给另一个工厂等，直到你到达你做出决定的地方。这通常是通过一个属性文件完成的，该文件包含与代码中的 - 语句相对应的标志if（这要求程序员在编写代码时预见所有情况）或要解析的类名Class.forName()（这很脆弱，因为编译器无法提供帮助）。

依赖注入的优点是，您可以new通过委派在您自己的代码之外创建适当对象的责任（给容器，但也可以是神）来回避操作员的硬绑定。您创建了一些非常清晰的切割线，您可以将它们放在一起，并且对于那些提供代码配置的 DI 框架（如 Guice），结果可以既坚固又模块化。

请注意，对接口进行编码可以更容易地确定为切割线制作切口的正确位置，因为接口使用通常对应于注入点。

于 2013-01-21T14:31:43.763 回答