生成器模式与依赖注入(例如通过 Guice)

2022-09-04 06:56:31

我正在开发一个简单的树形结构数据库,我通常通过生成器(生成器模式)设置依赖项或可选设置。现在我不确定何时使用例如 Guice,何时使用 Builder 模式,何时使用静态工厂方法而不是构造函数本身。我已经多次阅读了有效的Java,我认为它至少提到了很多不公开构造函数的优势。是时候重读了;-)

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


答案 1

我坚信你不需要对所有事情都使用依赖注入。

  • 对于论坛来说,很自然地注入了一个,这样它的实现就可以通过配置来交换出来。LookupServiceDictionary

  • 另一方面,对于论坛。它很自然地创建自己的,也许是通过供应或.FirewallFireWallRulesFactoryBuilder

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


考虑静态工厂 (*) 在以下情况下

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

以下情况下考虑实例工厂

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

以下情况下考虑建筑商

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

(*) 静态方法并不总是可测试的,在我看来,静态方法的存在应该始终受到激励。工厂的一个典型用例是减少耦合。通过使用一个能力是完全失去的。static factory


答案 2

生成器模式与依赖关系注入

这两者在你看来是如何接近可比的?
当您需要处理其构造函数将具有大量参数(可能是可选的)的类时,将使用生成器模式,并且此模式使您的代码更易于阅读和编写。

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


推荐