Putting the Object Pool inside of the Object's class

Question

I'm building an object pool and am find it really tedious to regularly reference a factory or and object pools to handle objects. Instead I'm considering building the pool directly into the object's class.

Abstract Object Class:

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)
 

Implementation:

@dataclass
class FooObject(Object):
    n: int

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

But when researching the ObjectPool design pattern it seems more common to separate the Pool, Objects, and use a Factory. Why is that and what problem would I run into with this method?

Answer 1

You can answer your question from different perspectives.

• Encapsulation: you do want to encapsulate the logic that is required to manage the pool.
• Information hiding: you do want to hide the internals of the pool logic from other objects like Object.
• Single responsibility: "A class should have only one reason to change"
• Decoupling: you don't want to force a dependency on an object only to use some of its functionality that is actually unrelated to the exposing object itself. For example, some classes are only interested in the pool e.g. to check ow many objects it contains. This class does not have to know Object. We must be able to access the pool without having to deal with the Object.
• Testability: we want to isolate the pool so that we can test it independently.
• Extensibility: we want to be able to extend the functionality of the pool e.g. by subclassing it.
• Maintainability (although following the previous principles already solved this): we don't want to be able to maintain the pool without having to touch the Object class. Pool and Object use completely independent logics. For example, Object could deal with user credentials. Why would such an object also contain the logic to manage the pool? Separating the two responsibilities also enables that a Pool and an Object class are in different logical locations (source files, DLL etc.) or physical locations (e.g. client-server).
• Reusability: we likely want to reuse our sophisticated pool in a different context or application, maybe with different object types. This is only possible if we separate the pool from the objects it pools.

If you understand some OO deign principles you feel that it is semantically the wrong design decision to have the Object to implement its own pool.
Unless you are a tortoise, a house and its inhabitant are two completely separate objects that share nothing. One uses the other. Both must exist individually. Both have different individual lifetimes. Both work and behave differently.

Although it is possible to have the object pool implemented by the Object itself it will produce ugly and overly complicated code and relationships between types.

If you can answer the following question, you can also answer your own question:

"Why don't we have a single big class that contains the application?"