将对象池嵌入对象类的实现：为何常规模式采用分离设计？存何问题？

我正在构建对象池，发现频繁引用工厂或对象池来处理对象十分繁琐，因此考虑将对象池直接嵌入对象的类中。以下是我的实现代码：

抽象对象类 #

from abc import ABC

class Object(ABC):
    _pool = []
    _max_pool_size = 10
    
    def __new__(cls, *args, **kwargs):
        if cls._pool:
            instance = cls._pool.pop()
            instance.__init__(*args, **kwargs)
            return instance
        else:
            return super().__new__(cls)
    
    @classmethod
    def release(cls, instance):
        if len(cls._pool) < cls._max_pool_size:
            cls._pool.append(instance)

具体实现 #

from dataclasses import dataclass

@dataclass
class FooObject(Object):
    n: int

foo_1 = FooObject(1)
FooObject.release(foo_1)

但查阅对象池设计模式相关资料后，发现更常见的做法是将池、对象分离并使用工厂模式。请问为何要采用这种设计？我的实现方式会遇到哪些问题？

一、分离式工厂+对象池设计的优势 #

• 单一职责原则：对象类专注于自身业务逻辑，对象池的创建、回收、容量控制等管理逻辑交给专门的池/工厂类，职责清晰，代码维护成本更低。
• 灵活性更强：可以随时替换对象池的实现（比如切换有界/无界池、调整回收策略），无需修改对象类代码；也能为同一个对象类配置多个独立池实例，适配不同场景需求。
• 可扩展性良好：后续要添加池监控（如统计创建/回收次数）、超时销毁、预热等功能，直接在池类中扩展即可，不会污染对象类的核心逻辑。
• 解耦对象与池：对象无需感知池的存在，脱离池环境后依然能正常工作，避免了强耦合带来的使用限制。

二、内嵌式实现的问题 #

• 违反单一职责：对象类既要实现业务功能，又要承担池管理逻辑，代码混杂，后续修改业务或池逻辑时容易互相干扰。
• 池逻辑无法复用：多个需要池功能的对象类，要么重复实现__new__和release，要么继承抽象类，但继承会增加耦合，且不需要池的类还要额外绕开相关逻辑。
• 无法独立配置池：所有同类型对象共享同一个静态池，没法给不同场景配置不同的池大小、回收策略。比如部分场景需要20个对象的池，另一部分只需要5个，这种需求无法满足。
• 对象回收风险：忘记调用release会导致内存泄漏；若已回收的对象被意外复用，__init__重新执行会覆盖原有状态，引发逻辑混乱。
• 继承隐患：子类重写__new__会破坏池逻辑；若子类未重新定义_pool，会与父类共享同一池，导致不同类型对象混存，取出时出现类型错误。

内容的提问来源于stack exchange，提问作者Jacob Simerly