设计模式下ConnectionPool实现与局限性探讨

本文档深入探讨了在设计数据库连接池时如何应用设计模式。作者首先提到在ResourcesCollector的设计中存在一个问题，即其内部使用了Java.util.Collection的具体实现，这可能会导致与资源管理器(ResourceMan)之间的耦合度过高。由于Collection接口定义了众多可选方法，这在理论上允许ResourceMan的实现者自定义容器，但实际操作中，如果这些方法在特定的容器中不被支持，可能导致运行时异常，如UnsupportedOperationException。 这种紧密的耦合使得为满足所有ResourcesCollector需求（如顺序和随机访问）而设计一个通用的容器接口变得困难，因为资源管理器与资源收集器的需求在概念上决定了某种程度的固定关联。作者认为，由于这种内在的需求耦合，很难找到一个完美的解来解耦这两个组件。然而，这并不影响整个数据库连接池框架的整体结构。 该框架的核心结构包括以下三个部分： 1. 可重用的pooling逻辑 - ResourceMan: 这个类实现了基本的池化算法逻辑，其设计目标是高度抽象，对具体资源类型保持最大程度的透明性，以便于适应不同的资源类型。 2. ResourceFactory: 负责封装资源生成过程，它将资源创建逻辑包装起来，并与ResourceMan结合，确保资源的高效管理和分配。 3. ResourcesCollector: 作为整体资源回收的管理器，它负责一组资源的生命周期管理，需要适配到ResourceMan中，以协调资源的获取、释放等操作。 虽然ResourcesCollector的设计存在局限性，但它作为框架中的一个子模块，其作用仅限于资源的组织和回收，不会对整个池化框架造成严重干扰。因此，尽管理想中的解可能难以实现，实际操作中可以通过适当的策略和设计模式来缓解这种耦合问题，确保系统的灵活性和稳定性。