Skip to content

Creational Design Pattern: Object Pool Pattern

The Idea behind the Object Pool pattern is pretty simple. In Object Pool Pattern you will not create a new object every time you need it. Also you’ll keep copies of already created object and provide these copies to the users as deem fit. You can even place a timeout to get the object back from the borrower after timeout.

Intent and Motivation

Think of Object Pool pattern as a Library. A library has a pool of books from which users can borrow books for their use. User will return the book when he/she finishes the book. This also propose one more idea that it’s always cheaper to have a library subscription and borrowing the book from there rather then buying a new book every time it’s needed. Implying above logic to object keeping an object pool makes sense. It’s always better to re-use the objects rather then creating new one every time. It results in more responsive application because it reuses same object between multiple subscribers or clients. Hence cost of creating and using object (memory and CPU time) reduces by a great deal.

One more example can be of a company. Let’s say you just started a company and procured 10 laptops for the use within the company. Company’s warehouse stores these laptops. Now as employees joins the company you check the warehouse whether a laptop is present or not. If yes then you’ll provide the laptop to the new employee else you go ahead and buy a new one. After any employee quits the job their laptop will be returned back to the warehouse. The company will sell all the laptop that are not in use and their usage period is expired. This is exactly how object-pool works.

General Pool Flow

From the above details we can deduce that the flow in Object Pool would be as follows:

  1. Any process will request a checkout of object from the pool whenever it needs an object.
  2. Provide an object to the process.
    1. If pool has the object it will provide the object to the process.
    2. If pool does not have object then create a new object and provide that object to the process.
  3. As soon as process finishes its task and no longer require the object then it will return the object back the Object Pool.
  4. Cleanup the the object to free up memory when any object’s time is expired and it is no longer in use.

Example

Above flow can be best explained by using an example.

Object Pool Pattern UML diagram
Object Pool Pattern UML diagram

Package structure

Object Pool Pattern Package Structure
Object Pool Pattern Package Structure

First we need to make sure that only our pool can make objects of the class. For this we will create our Pool class in the same package as of our Object Class. Other class must not present in that package. This will guarantee that only Pool class will create a new object.

Object Class

ObjectPoolExample will use the SomeObject class’s object. Only SomeObjectPool class will be able to create the object of the SomeObject Class.

Look at the SomeObject class.

Abstract Pool Class

We’ll try to create a pool of “SomeObject” objects. First we need an abstraction layer for the pool. We will define a generic pool class that is equipped to handle any objects creation and deletion. Here’s the definition for AbsObjectPool class.

Concrete Pool Implementation and Usage

The only thing left right now is to implement a concrete pool implementation. This is done via extending AbsObjectPool and providing SomeObject in the generic. The implementation would be pretty straight forward. Lets take a look at it.

This is it, now we’ll see how the client code would handle it to finish our discussion with the Object Pool Pattern.

Well this is it for the Object Pool Pattern. I hope the text is understandable and clear. If you find any issues comments are always welcome.

As always thanks for reading.

Cheers!!

Published inDesign Patterns

Be First to Comment

    Leave a Reply

    Your email address will not be published. Required fields are marked *