静态工厂和依赖注入

Question

在Effective Java (书)中，推荐使用静态工厂。

另一方面，建议保持依赖关系的显式，例如通过使用DI。

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

这两样东西怎么能搭配在一起呢？

Answer 1

真是个好问题。

静态工厂确实有这个缺点(还有其他缺点)：它们不明确，因此不能用作可切换的依赖项。

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

所以这是一个设计的选择。

就我个人而言，我使用工厂方法，因为我不想允许显式地设置工厂返回的依赖项。

这就是您想要掌握对象创建的情况:一致性、缓存等等。并且您希望提供一个清晰的API。这是一种非常直接的方式来保证这一点。

使用依赖注入设置对象将不会提供这一点。

一般来说，我这样做是为了那些我既不想提供替代实现也不想在单元测试期间模拟的类。

这就是我想要掌握创建的业务/模型类的情况，以及一些“实用”类。

但是，一旦需要显式设置依赖关系，我就重构静态工厂，使其能够显式设置依赖关系。

如果对象创建的主节点总是必需的，我会将静态工厂转换为我注入的实例工厂。

否则，我将直接注入工厂返回的对象。

Answer 2

这个问题有两个方面：

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

工厂、构造函数和自动解析容器是改变对象创建方式的方法(问题2)。这与对象如何允许自身创建是完全不同的(问题1)。

作为一般启发式：

正在创建的

1. 对象在如何构造方面应该尽可能灵活，并且应该在其构造函数中显式地通告它们的所有依赖项(即使构造函数是私有的，而工厂是由创建者使用的)。
2. 创建者应该与他们创建的对象解耦，因为您的应用程序需要保持其灵活性。可以直接依赖高度稳定的依赖项。可能会更改或被替换的依赖项不应

静态工厂、实例工厂、构造函数和容器自动解析之间的差异在很大程度上只是语法。最大的区别是语义表达(它传达给开发人员关于程序结构的内容)和在运行时解析不同实现的能力。

为了回答你的核心问题，这两件事可以结合在一起，因为它们是问题的不同部分的解决方案。您可以将它们一起使用。