java Builder模式与依赖项注入（例如通过Guice）

Question

我正在开发一个简单的树结构数据库，我通常通过构建器（构建器模式）设置依赖项或可选设置。现在我不确定什么时候使用实例Guice，什么时候使用Builder模式，什么时候使用静态工厂方法而不是构造函数本身。我已经读过好几次有效的Java，我认为它至少提到了不公开构造函数的许多优点。是时候重读了；-）

那么，你知道哪些案例是可以清晰区分的吗？我不应该暴露构造器吗？例如，在每种情况下写public static Foo getInstance(...) { return new Foo(...)}

Answer 1

我坚信，你不需要为一切使用依赖注入

• 对于LookupService来说，注入a Dictionary是很自然的，这样就可以通过配置替换它的实现

• 另一方面，对于Firewall。它自然会创建自己的FireWallRules，可能是通过提供的Factory或Builder

作为指导原则，注入配置所需的，不要自动注入其他所有内容

---

考虑<<强> ^ {< CD7>}>

• 需要命名的构造逻辑。例如，Lists.newArrayList()
• 这个结构非常复杂，不属于这个类本身
• 不需要配置工厂，工厂没有副作用

考虑<<强> ^ {}>

• 有复杂的实例化逻辑
• 需要对工厂进行配置
• 使用AbstractFactory设计模式
• 在整个程序生命周期中，需要创建额外的对象

当

时考虑<强> ^ {CD11>}>

• 有复杂的参数选择。例如，5个参数，其中一些是可选的

---

(*)静态方法并不总是可测试的，在我看来，静态方法的存在应该总是有动机的。 工厂的典型用例是减少耦合。通过使用static factory，这种能力完全丧失

Answer 2

我已经开始在我的大多数项目中使用builder，结果证明我可以并且已经用builder和singleton替换了我的所有DI

例如：

AppContext appContext = new AppContext.Builder()
.setProperties(testProps)
.setDB(testDB)
.build();

// run tests

我的代码在没有DI的情况下变得更易于管理

Answer 3

Builder pattern vs. Dependency Injection

在你的心目中，这两个是如何接近的
当您需要处理其构造函数包含大量参数（可能是可选的）的类时，可以使用生成器模式，该模式使代码更易于读写

依赖项注入是一种有助于松散耦合的方法，可以消除高层类与底层类之间的依赖关系。例如，需要连接到数据库的类不会直接创建连接，但会“注入”连接，并且该连接可以交换到不同的数据库，而不会影响使用它的代码