静态工厂和依赖注入

Question

在Effective Java（书籍）中，建议使用静态工厂。

另一方面，建议保持依赖关系明确，例如使用DI。

但是当我想使用静态工厂时，将跳过此显式性，因为将通过调用静态工厂方法来接收对象实例。 使用静态工厂方法，我不必传入包含静态工厂的对象。

这两件事怎么结合在一起呢？

Answer 1

真好问题。
静态工厂确实存在这个缺点（其中包括）：它们不是显式的，因此它们不能用作可切换的依赖项。

我不认为你可以让这两件事一起工作，因为静态方法与类相关联，而依赖注入与实例相关联。
所以它是一种设计选择。

就个人而言，我使用工厂方法，因为我不想允许显式设置工厂返回的依赖项。
在这种情况下，您希望掌握对象创建：一致性，缓存等......并且您希望提供一个清晰的API。 这是一种非常直接的方式来保证这一点。
设置具有依赖注入的对象不会提供。

一般来说，我是为那些我不希望既不提供替代实现也不想在单元测试期间进行模拟的类做的。
我希望掌握创建的业务/模型类以及一些“实用程序”类的情况。
但是一旦需要显式设置依赖关系，我就会将静态工厂重构为允许显式设置依赖关系的东西。
如果始终需要创建对象的主体，我将静态工厂转换为我注入的实例工厂。
否则我直接注入工厂返回的对象。

Answer 2

这个问题有两个方面：

1. 正在创建的对象。
2. 正在进行创建的对象。

工厂，构造函数和自动解析容器是改变对象创建方式的手段（问题2）。 这与对象允许自己创建的方式完全不同（问题1）。

作为一般启发式：

1. 正在创建的对象在构造方式方面应该尽可能灵活，并且应该在其构造函数中明确地宣传它们的所有依赖项（即使构造函数是私有的，创建者也使用工厂）。

2. 创建者应该与他们创建的对象分离，因为应用程序需要保持其灵活性。 高度稳定的依赖关系可以直接依赖。 可能会改变或被替换的依赖性不应该

静态工厂，实例工厂，构造函数和容器自动解析之间的差异主要只是语法。 最大的区别是语义表达（它与开发人员就程序结构进行通信）以及在运行时解析不同实现的能力。

要回答你的核心问题，这两件事可以结合在一起，因为它们是分离问题的一半的解决方案。 你可以一起使用它们。