构建器模式与依赖注入(例如通过Guice)

Question

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

那么,您是否知道明显可区分的案例？我不应该暴露构造函数？因此,例如在每种情况下写public static Foo getInstance(...) { return new Foo(...)}？

Answer 1

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

• 对于a LookupService来说,自然会注入一个Dictionary这样的实现,即它的实现可以通过配置进行交换.

• Firewall另一方面,对于一个.它可能很自然地创造它自己的FireWallRules,也许通过提供Factory或者Builder.

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

考虑static factory (*)何时

• 需要命名构造逻辑.例如,Lists.newArrayList()
• 建筑如此复杂,不属于班级本身
• 不需要工厂配置,工厂没有副作用

考虑instance factories何时

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

考虑builder何时

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

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

Answer 2

构建器模式与依赖注入

这些2 在您的脑海中甚至接近可比性如何？
该生成器模式,当你需要处理类,它们的构造函数可以有参数(可能可选)的绝大多数使用该图案让你的代码更易于读取和写入.

依赖注入是一种有助于松散耦合的方法,可以将更高级别类的依赖性移除到更低级别的类.例如,需要连接到数据库的类不会直接创建连接,而是"注入"连接,并且可以将此连接交换到其他数据库,而不会影响使用它的代码.