容器

对象的生命周期管理

对象的生命周期管理在基于面向对象的编程语言中是一个永恒的话题。从语法上讲，面向对象的高级编程语言都是以“对象”为中心的。而对象之间的继承关系、嵌套引用关系所形成的对象树结构为我们进行对象级别的逻辑操作提供了足够的语法支持。但这样一来，对象之间所形成的复杂关系也为生命周期的管理带来了问题：

• 在程序的运行期，应如何创建我们所需要的对象？

• 当创建一个新的对象时，如何保证与这个对象所关联的依赖关系（其关联对象）也能够正确地创建出来？

结论   为了更好地管理好对象的生命周期，我们有必要在程序逻辑中引入一个额外的编程元素，这个元素就是容器（Container）

以上两大问题，实际上涵盖了对象生命周期管理的两个不同方面：

• 在程序的运行期，对象实例的创建和引用机制
• 对象与其关联对象的依赖关系的处理机制

当对象之间的这种依赖关系与运行期（Runtime）对象的构建机制相结合时，情况就会变得更为复杂。因为在对象创建的时候，除了需要考虑这个对象本身作为一个实例的创建过程，还需要考虑与这个对象形成依赖关系的关联对象的实例化过程。在这里，前一个过程能够使对象自身的生命周期得到控制和管理；而后一个过程，则保证了程序在运行期的使用不会受到其所依赖的对象的生命周期的限制

因此，我们可以看出对象的生命周期管理的两个不同方面的内容是密不可分的。对象的创建是对象依赖关系管理的基础，没有对象的创建过程，其所关联的依赖对象的生命周期也就无从谈起；另外一个方面，如果对象的依赖关系无法被正确处理，那么我们创建出来的对象也就失去了基本的活力，因为它失去了一个对象最为基本的与其他对象协同合作的能力

容器的引入

如果没有控制反转，实现获取依赖对象的过程靠程序逻辑自身来实现（也就是说在程序的运行过程中自行管理），那么我们至少可以预见到这种编程模式存在的三大弊端：

• 对象将频繁创建，效率大大降低（尽管在大多数情况下，这些对象都是无状态的单例对象）

• 对象的创建逻辑与业务逻辑代码高度耦合，使得一个对象的逻辑关注度大大分散

• 程序的执行效率大大降低，由于无法区分明确的职责，很难针对对象实现的业务逻辑进行单元测试

正因如此，引入一个与具体的业务逻辑完全无关的额外的编程元素容器来帮助进行对象的生命周期管理。既然引入容器的目的是为了解决对象生命周期管理中所遇到的问题，那么这一额外的编程元素自身的设计也应该遵循一定的原则：

• 容器应该被设计成一个全局的、统一的编程元素

• 在最大程度上降低容器对业务逻辑的入侵

• 容器应该提供简单而全面的对象操作接口

容器（Container），不是容器（Collection）

容器（Collection），是一个具体的数据结构类。在容器（Collection）之中存储的内容是对象。而容器（Container），却不是一个具体的数据结构类，它用于管理对象的生命周期，我们可以把它看作是一个全局的编程元素。因此，在容器（Container）之中，我们将看不到具体的对象存储。整个容器（Container）从外部看来，就如同是一个可以进行对象操作的工作类

结论 容器（Container）由一系列对象的操作接口构成，其中应该至少包含获取对象实例以及管理对象之间的依赖关系这两类操作方法。

---

参考：整理归纳自《struts2技术内幕——深入解析struts2架构设计与实现原理》