The Object Pool
Intent: Create a manager class to represent a pool of reusable resources. Clients will access the manager to obtain an instance of the resource and return it when their task is complete.
Example: Connections are to be made to a data resource on a server. The server will allow from 1 to 255 connections to be made. If one connection is made, then clients must wait for the connection to be available, but the server's performance will be fast. If 255 connections are made, then clients need not wait for an available connection, but the server will bog down servicing so many connections. It is unpredictable what the best balance point is for optimal throughput.
An object pool could be used to manage a set of reusable connection objects. The number of objects is encapsulated and thus easy to change.
Figure 14: Object pool example diagram.
Qualities and Principles: The object pool separates the concerns of use from creation, but also the nature of the pool itself. How many objects are in it, if they are reused or remade each time, if they are used by more than one client (load-balanced), all these things are encapsulated and therefore easily changeable. The managed objects are substitutable for each other.
Testing: Testing the manager itself is fairly straightforward:
Questions and Concerns: One decision that must always be addressed with the object pool is whether or not to make the pool size dynamic. The setPoolSize(int)
method is optional and should only be added if changing the pool size will not violate any system contracts, and if different application contexts will require it. The default option is to keep the pool size static.
For more information: https://tinyurl.com/y6jrmbhv
18.118.152.58