哪种设计模式?

一堆“相似”的物体?池的性质是,当您从池中请求一个项目时,您不知道得到的是哪个项目。所以相似是不够的,它们必须是相同的。

但是他们被锁起来了?所以它们是不同的?所以当你得到一个对象时,你可以用某种方式“配置”它。这个配置可以撤消,这样对象就可以返回池了?

所以我的第一个问题是:为什么不在需要的时候“新建”对象,然后在完成后删除它们(或者让它们gc-ed)?

你不会说是什么驱使你想到游泳池。创建这些对象的成本是否非常高?模式需要上下文,您没有提供足够的信息让我们评论池的适当性。

一个想法:模式==code,代码==bug。更少的代码==更少的错误。尽你所能保持简单。

责任链的想法听起来似乎是合理的,但你又没有提供足够的信息。“链条”的顺序重要吗?如何确定?它会随时间变化吗?它真的是一个链条还是更像一个“网”。所有对象都转换数据吗?转换的含义是什么?这可能会影响链中以前的项对对象的看法吗?

听起来你的处理过程非常灵活。你是否建立了过度的灵活性?什么要求导致了这个“链”概念?

您需要提供关于如何使用这些对象的更多详细信息。互动吗?

您还需要一个管理器来管理对象的生命周期(创建、分发)。管理器通常作为 singleton …也考虑一个 builder 创建对象的模式。

您似乎已经确定了密钥模式,但我不确定“池中的对象”在它们之间有什么不同(如果有),也就是说,在将(可能修改的)数据传递到链中的下一个对象(或断开链)之前,每个对象如何知道执行可能不同的处理?如果这些物体在游泳池里,我想它们最好是没有区别和无法辨别的——所以,你需要一个 策略 同样的模式,使这些相同的对象执行不同的处理和逻辑…?