What is it? The object pool design pattern exposes a manager to manage a pool of reusable objects. The idea is to keep a know number of reusable objects (with a hard limit to initialize some more lazily). Whenever someone need the object from the pool, it will ask the pool manager. If there are free objects, the manager will engage one for your. If there aren’t any free objects but the hard limit is not breached, then the manager will initialize a new object and provide you.
Understanding the problem Let’s say you have a very large log file. And you want to create an app that can analyze this file and generate insights. Also, let’s say you want to create an another app that can simulate the work by reading the logs one-by-one.
Both these apps are dependent on the same log file. Now, there are 2 scenarios.
App1 starts, downloads the file and then App2 starts.
Where is this used? This is used to analyze/modify the behaviour of a class at runtime. Using this, you can view or change the private/public fields at wish (without exposing any getter/setter). Personally, I have used this in one of our projects at GreyOrange to write unit test cases. Using this in main code is a big no-no as it exposed you critical fields to the world.
Main Class Let’s create a main class for which we will write some test cases.