When it is necessary to work with a large number of objects that are particularly expensive to instantiate and each object is only needed for a short period of time, the performance of an entire application may be adversely affected. An object pool design pattern may be deemed desirable in cases such as these. The object pool pattern is a design pattern that uses a set of initialized objects kept ready to use a "pool" - rather than allocating and destroying them on demand. A client of the pool will request an object from the pool and perform operations on the received object. When the client has finished, it returns the object to the pool rather than destroying it, allowing it to be used again in the future without repeating the computationally expensive instantiation process. It is important to note that once an object has been used and returned, existing references will become invalid to the client. When a new object is needed, it is requested from the pool. If a previously prepared object is available, it is returned immediately, avoiding the instantiation cost. If no objects are present in the pool, a new object is created and returned. In some object pools, the resources are limited to a specified maximum number of objects. If this number is reached and a new object is requested, the thread will be blocked until an object is released back into the pool. Object pools are primarily used for performance. For example, a connection pool is a cache of database connections maintained so that the connections can be reused when future requests to the database are required. Connection pools are used to enhance the performance of executing commands on a database. Opening and maintaining a database connection for each client, especially requests made to a dynamic database-driven website application, is costly and wastes resources. In connection pooling, after a connection is created, it is placed in the pool and it is used again so that a new connection does not have to be established. If all the connections are being used, a new connection is made and is added to the pool. Connection pooling also cuts down on the amount of time a user must wait to establish a connection to the database. Consider a dummy ServiceObject class that has a single state variable (String myState) and a single method do something () that just prints "myState". Each client of ServiceObject will have its own "myState" a) Design and implement a class(es) that allows a pool of a specified number (n) of instances of ServiceObject. The class(es) should offer the following methods: getInstance(): returns to a client an instance if one is available. If no instance is available and the maximum number of instances (n) is not reached, an instance is created and returned. The instance returned by the getInstance () method should not be used again until" released. release Instance (ServiceObject): releases the object for future use