12

我正在开发一个简单的树结构数据库，我通常通过 Builder（Builder 模式）设置依赖项或可选设置。现在我不确定何时使用 Guice，何时使用 Builder 模式以及何时使用静态工厂方法而不是构造函数本身。我已经多次阅读 Effective Java，我认为它至少提到了不暴露构造函数的很多优点。是时候重读了 ;-)

那么，您知道哪些案例可以清晰区分吗？我不应该公开构造函数吗？因此，例如在每种情况下都写public static Foo getInstance(...) { return new Foo(...)}？

4

3 回答 3

15

我坚信您不需要对所有内容都使用依赖注入。

  • 对于 aLookupService来说，很自然地注入aDictionary这样它的实现可以通过配置换出。

  • Firewall另一方面。它会很自然地创建自己的FireWallRules，也许是通过提供的Factory或Builder.

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

考虑一下什么static factory (*)时候

  • 需要命名构造逻辑。例如，Lists.newArrayList()
  • 结构如此复杂，它不属于类本身
  • 无需工厂配置，工厂无副作用

考虑instance factories什么时候

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

考虑一下什么builder时候

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

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

于 2012-09-20T21:05:34.283 回答
13

构建器模式与依赖注入

这两个在你心目中如何接近可比性？
当您需要处理其构造函数将具有大量参数（可能是可选的）的类时，使用 构建器模式，并且此模式使您的代码更易于阅读和编写。

依赖注入是一种促进松散耦合的方法，它消除了较高级别类与较低级别类的依赖关系。例如，需要连接到数据库的类不会直接创建连接，而是“注入”连接，并且可以将该连接交换到不同的数据库而不影响使用它的代码。

于 2012-09-20T21:23:50.200 回答
2

我已经开始在我的大部分项目中使用构建器，事实证明我可以并且已经用构建器和单例替换了我所有的 DI。

IE：

AppContext appContext = new AppContext.Builder()
.setProperties(testProps)
.setDB（测试数据库）
。建造（）;

// 运行测试

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

于 2015-03-04T20:10:09.787 回答