The core concept of this pattern is simple—a pool in the form of a container holds a collection of initialized objects in memory. Clients can request an Object Pool for an object instance of a specific type; if one is available, it will be removed from the pool and given to the client. If there are not enough pooled instances at a given time, new ones will be dynamically created.
Objects that exit the pool will attempt to return to it once they are not used anymore by the client. If the Object Pool has no more space, it will destroy instances of objects that attempt to return. Therefore, the pool constantly gets refilled, can only be temporarily drained, but never overflows. Hence, its memory usage is consistent.
The following diagram illustrates the back and forth between a client and an Object Pool:
In the diagram, we can see that the Object...