design-patterns - 对象池模式 - 关注点分离 - 封装 : Who is responsible for deleting an instance?

Question

情况

在开发过程中，我实现了称为对象池模式的设计模式。
基本上这意味着我们的类有一个静态的公共(public)方法和一个静态保护的属性。该属性携带所有实例，如果提供了某个对象键，则可以通过静态公共(public)方法检索这些实例。
我使用一种名为 get_instance 的方法将实例检索到本地引用变量中，然后在其上调用其他方法。
在我们的例子中，包装函数模块调用 get_instance ，然后在该实例上调用一些方法。在特定情况下，某个实例的生命周期结束。
因此，它必须从对象池中删除。
到目前为止，我在实例方法中执行此操作，其中对象从池(表)中删除自身。

假设

功能模块中的外部引用应该已经失效，因为它确实引用了一个不存在的对象。如果我假设正确，垃圾收集器现在应该携带这个孤立的引用。 (通常情况相反:一个未引用的对象通常被 GC 杀死。)在这种情况下，我仍然假设我的功能模块中的本地引用也应该被收集。因为它所引用的对象已从对象池中删除。尽管如此，直到现在，我仍然调用Free lr_myreference .
一位同事说，在调用 Free lr_myreference 之前，最好实现一个静态公共(public)方法，它不会作用于引用，而只是简单地杀死池的条目。 .

问题

一般来说，我在想:谁负责从池中删除对象？其他本地引用文献指的是什么？
表中的条目(“原始引用”)？

Answer 1

我经常使用您描述的相同模式，最好将一些哈希表保存为工厂/管理器/池类的静态属性。

就个人而言，我尽量避免需要明确完成的对象。根据我的经验，随着应用程序变得越来越复杂，总会有人倾向于忘记最终确定。反过来，这可能会导致许多众所周知的难以调试的不良副作用。我尝试遵循这样一个基本假设，即垃圾收集器最清楚何时删除一个对象，并且一旦对象消失，这就是全部。只要任何人(一个函数组，另一个类，没关系)保持对一个对象的引用，它仍然在使用中并且不会被 gc'ed。除了需要频繁显式解构对象实例的控制框架之外，这种方法效果很好。

这种方法的明显缺点是对象池将趋于增长，除非实现得当。我的实例哈希表不包含对实例的硬引用；相反，我使用 CL_ABAP_WEAK_REFERENCE跟踪托管对象。这允许垃圾收集器删除所有未在其他地方使用的托管实例。当然，这也意味着您需要通过其他直接引用来跟踪您仍然需要的实例(例如，使用封装了 ENQUEUE/DEQUEUE 调用并同时用作锁定 token 的锁定对象 - 无论谁是当前所有者该对象也负责再次释放锁)。

警告:在广泛使用弱引用时，必须避免一个相当常见的结构错误。 我写了一个 SCN article前段时间包含一个(反)示例。底线:如果通过弱引用引用管理对象(在您的示例中，池类)，请确保托管实例具有对管理器的硬引用 - 否则您可能会意外地得到几组托管实例代表同一件事。