为什么Spring依赖注入有init-method？

Question

我来自.NET背景，使用过Unity、Ninject、Castle Windsor等依赖注入容器。最近开始学习使用Spring对Java的依赖注入能力。

在学习 Spring 时，我发现可以在 bean XML 配置中指定“init-method”和“destroy-method”的概念。

指定“init-method”的目的似乎是在创建 bean 时进行您可能想做的任何设置。这就是我感到困惑的地方。为什么您需要一个单独的方法来执行设置，而不是像普通/良好的面向对象设计那样仅使用构造函数来执行对象所需的任何设置？

换句话说，如果一个类需要一个依赖项，它不应该被注入到构造函数中吗，你知道已经被调用了，而对象可以在没有的状态下存在称之为“初始化方法”？

Answer 1

如果您使用的是 setter 注入，那么肯定需要 init 方法/InitializingBean/@PostConstruct 以便在所有属性都已设置/自动装配后进行初始化。否则你有一个构造但不是依赖注入的对象。如果您使用的是构造函数注入，则很少需要它，在 Tomasz 和 Stephen 指出的情况下。

Answer 2

在少数情况下需要单独的init() 方法：

• 您别无选择的旧版 API

• 初始化有一些副作用，例如启动Thread，连接到外部资源

  这实际上具有更深层次的含义：当使用基于类的代理（通过cglib）时，基类的构造函数被调用两次（第二次是从你的类继承的代理）- 仅调用init() 方法一次在最终对象上。

• 你不应该在构造函数中执行虚拟调用（这实际上应该被编译器禁止......）

• 有时您必须使用 setter/field 注入（尽管我喜欢构造函数注入），例如当使用上述基于类的代理时

使用构造函数来执行对象所需的任何设置，就像正常/良好的面向对象设计一样？

这实际上并不是将所有初始化代码放在构造函数中的最佳做法。构造函数中的副作用使测试和模拟变得更加困难。而是专注于创建 stable 和 known 状态的对象。这样你可以例如解耦创建一个管理连接池的对象并物理连接到该池。

顺便说一句，destroy() 是一种没有析构函数的语言的福音，因为它允许您感激地关闭外部资源、中断线程等。经常使用它。

Answer 3

你为什么需要它？

在设置完所有 bean 的属性后调用 init 方法。如果 bean 需要对属性进行一些初始化或验证，而这些属性只能在设置完所有属性后完成，则通常需要这样做。 （如果您尝试在没有“init”回调的情况下执行此操作，您会发现每个属性设置器都必须检查其他设置器是否已被调用，依此类推。如果只能在所有属性之后进行初始化，那么即使该策略也会失败在一个循环的beans中已经设置好了。）

如果bean持有需要显式释放的资源，则需要destroy方法；例如文件句柄、网络套接字、数据库连接。

... 像正常/良好的面向对象设计一样吗？

任何规定 init 和 destroy 事件/方法是“错误”或“禁止”的设计方法都是不现实的，应该被忽略。事实上，面向对象的设计方法通常不会规定这一点。最多他们会说这种东西通常不需要。

此外，DI 实际上在一定程度上改变了设计方法的规则……至少在初始化方面。特别是，通过将实例的“连接”外部化，它以经典 OO 设计方法没有预料到的方式从代码中提取出很多逻辑。如果有的话，这就是说需要根据依赖注入重新审视经典的 OO 方法。