有效的Java项目1适用于TDD和依赖注入

Question

我一直在阅读Effective Java,我对第一个项目"使用静态工厂方法而不是构造函数"与TDD和依赖注入有关.

该项目表示您应该避免使用public/protected/default构造函数并使用静态工厂公开它.我同意与使用静态工厂相关的所有优点,例如工厂可以有名称,你可以返回子类型,你可以减少冗长等等.但是,我认为缺点是约书亚错过了TDD,因为你的代码中有静态工厂将导致紧密耦合和你不能用它来模拟这个类.我们将无法模拟将拥有静态工厂的类.因此,它阻碍了测试驱动的开发.

第二点,我认为他错过了在今天的企业开发中大多数应用程序使用一个或另一个依赖注入容器.所以,当我们可以使用DI注入依赖项时,为什么要使用它呢？

请解释它如何应用于今天的Java企业开发,包括DI和TDD.

Answer 1

DI 引擎是工厂。

Joshua Bloch 非常了解 DI。我认为这是历史的产物，因为 DI 的崛起是在“Effective Java”第一版之后。

《Effective Java》于2001年出版。 Martin Fowler在 2004 年创造了这个词 。Spring 的 1.0 版本于 2004 年 3 月发布。

Joshua Bloch 没有修改第二版的那一章。

重点是“新”引入的耦合。任何了解这一点和工厂的人都会很容易地飞跃到 DI 引擎。关键是他关于“新”的说法，以及使用工厂的补救措施，仍然是正确的。

Answer 2

我在这里看到两个单独的问题：

• 静态工厂与使用 new()
• 依赖注入

当使用 new 时，您的代码与使用静态方法一样紧密耦合，实际上甚至更糟，因为静态工厂可以发挥一些作用并返回一些特定的实现，只要它是接口的子类或实现。

依赖注入的原则也称为好莱坞原则：“不要打电话给我们，我们会打电话给你”。因此，按照这种理念，您不应该在代码中调用 new() 或静态工厂，而应该让外部事物为您执行此操作，无论是 DI 框架还是单元测试。这与工厂或 new 的使用无关，因为这是在其他地方完成的。

在这种情况下，工厂会更好，因为您可以在您的控制下注入一个测试工厂。对于 new 这是不可能的（不对类路径做奇怪的事情，比如在测试类路径中隐藏带有虚拟对象的实现，顺便说一句，我不建议这样做）。