实现驱动和依赖注入的好处与维护实现的成本

我正在启动一个我希望快速构建的应用程序，稍后将由20多位开发人员开发。实现驱动和依赖注入的好处与维护实现的成本

在一个包含多个开发人员的环境中了解您对DI的了解，您是否愿意与DI一起创建一个您希望构建得相对较快的新应用程序？

现在对我使用DI的成本将是写入和生成的代码行，而不是使用每个对象的接口。并且，我希望DI由于反思而不会成为性能问题。

2011-10-18 MetaChrome

简单地说，在没有依赖注入的情况下进行面向对象的开发是不好的。很坏。在我看来，依赖注入是众所周知的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-12 23:22:25 Guillaume

DI基本上不是框架。例如，如果只是将你的依赖关系作为参数添加到缩尺，那么你就是在做DI。实际上，你甚至不需要创建接口（尽管这将有助于测试。稍后介绍接口是对Java等语言的简单重构）。 DI只是消除了课堂用户的创作责任。

我脑海中唯一最大的代价就是心灵的变化。学会思考DI。的好处包括更容易的测试。分离关注和更多。

来源

2011-11-12 23:11:11 mathiasbn

没有接口，在类和它的依赖之间保持紧密耦合，这是DI尝试破坏的一件事。这将是一个耻辱。 – Guillaume

确实。只是要指出，对于快速Spike，界面决定可以推迟 – mathiasbn

我绝对会主张DI，特别是当有很多开发者时。

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

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

来源

2011-11-12 23:17:00

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

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

然而，你经常需要推迟一些设计问题来部署时间（偶尔甚至是运行时），而在Java中处理这种情况的方式传统上是委托给工厂，甚至可能委托给另一工厂等，直到你到达你作出决定的地方。这通常是通过一个属性文件来完成的，该文件包含代码中对应于if的标志（需要编程人员在编写代码时预见所有情况）或类名称以解决Class.forName()（编译器无法帮助）。

依赖注入的优势在于，您可以通过将自己的代码之外的适当对象委托给一个容器（但也可能是一个神）来避免new运算符的硬绑定。你可以创建一些非常明确的界限，你可以把所有的东西放在一起，对于那些提供代码配置的DI框架（比如Guice），结果可以像模块一样坚固。

请注意，对接口进行编码可以更容易地找到切割切口的正确位置，因为接口用法通常对应于注射点。

来源

2013-01-21 14:31:43

实现驱动和依赖注入的好处与维护实现的成本

回答

相关问题