#Design_Patterns

#Object_Pool_Design_Pattern

👉Discussion

The Object Pool lets others "check out" objects from its pool, when those objects are no longer needed by their processes, they are returned to the pool in order to be reused.

However, we don't want a process to have to wait for a particular object to be released, so the Object Pool also instantiates new objects as they are required, but must also implement a facility to clean up unused objects periodically.

@javaCode☕️

#Design_Patterns

#Object_Pool_Design_Pattern

👉Structure

The general idea for the Connection Pool pattern is that if instances of a class can be reused, you avoid creating instances of the class by reusing them.

▪️Reusable - Instances of classes in this role collaborate with other objects for a limited amount of time, then they are no longer needed for that collaboration.

▪️Client - Instances of classes in this role use Reusable objects.

▪️ReusablePool - Instances of classes in this role manage Reusable objects for use by Client objects.

Usually, it is desirable to keep all Reusable objects that are not currently in use in the same object pool so that they can be managed by one coherent policy. To achieve this, the ReusablePool class is designed to be a singleton class. Its constructor(s) are private, which forces other classes to call its getInstance method to get the one instance of the ReusablePool class.

A Client object calls a ReusablePool object's acquireReusable method when it needs a Reusable object. A ReusablePool object maintains a collection of Reusable objects. It uses the collection of Reusable objects to contain a pool of Reusable objects that are not currently in use.

If there are any Reusable objects in the pool when the acquireReusable method is called, it removes a Reusable object from the pool and returns it. If the pool is empty, then the acquireReusable method creates a Reusable object if it can. If the acquireReusable method cannot create a new Reusable object, then it waits until a Reusable object is returned to the collection.

Client objects pass a Reusable object to a ReusablePool object's releaseReusable method when they are finished with the object. The releaseReusable method returns a Reusable object to the pool of Reusable objects that are not in use.

In many applications of the Object Pool pattern, there are reasons for limiting the total number of Reusable objects that may exist. In such cases, the ReusablePool object that creates Reusable objects is responsible for not creating more than a specified maximum number of Reusable objects. If ReusablePool objects are responsible for limiting the number of objects they will create, then the ReusablePool class will have a method for specifying the maximum number of objects to be created. That method is indicated in the above diagram as setMaxPoolSize.

@javaCode☕️

#Design_Patterns
#Object_Pool_Design_Pattern

👉Example

Object pool pattern is similar to an office warehouse. When a new employee is hired, office manager has to prepare a work space for him. She figures whether or not there's a spare equipment in the office warehouse. If so, she uses it. If not, she places an order to purchase new equipment from Amazon. In case if an employee is fired, his equipment is moved to warehouse, where it could be taken when new work place will be needed.

@javaCode☕️

#Design_Patterns

#Object_Pool_Design_Pattern

👉Check list

1️⃣Create ObjectPool class with private array of Objects inside

2️⃣Create acquire and release methods in ObjectPool class

3️⃣Make sure that your ObjectPool is Singleton


👉Rules of thumb

▪️The Factory Method pattern can be used to encapsulate the creation logic for objects. However, it does not manage them after their creation, the object pool pattern keeps track of the objects it creates.

▪️Object Pools are usually implemented as Singletons.

@javaCode☕️

#Design_Patterns

#Creational_patterns

#Prototype_Design_Pattern

👉Intent

Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.
Co-opt one instance of a class for use as a breeder of all future instances.
The new operator considered harmful.

@javaCode☕️

#Design_Patterns
#Prototype_Design_Pattern

👉Problem

Application "hard wires" the class of object to create in each "new" expression.

@javaCode☕️

#Design_Patterns
#Prototype_Design_Pattern

👉Discussion

Declare an abstract base class that specifies a pure virtual "clone" method, and, maintains a dictionary of all "cloneable" concrete derived classes. Any class that needs a "polymorphic constructor" capability: derives itself from the abstract base class, registers its prototypical instance, and implements the clone() operation.

The client then, instead of writing code that invokes the "new" operator on a hard-wired class name, calls a "clone" operation on the abstract base class, supplying a string or enumerated data type that designates the particular concrete derived class desired.

@javaCode☕️

#Design_Patterns
#Prototype_Design_Pattern

👉Example

The Prototype pattern specifies the kind of objects to create using a prototypical instance. Prototypes of new products are often built prior to full production, but in this example, the prototype is passive and does not participate in copying itself. The mitotic division of a cell - resulting in two identical cells - is an example of a prototype that plays an active role in copying itself and thus, demonstrates the Prototype pattern. When a cell splits, two cells of identical genotype result. In other words, the cell clones itself.

@javaCode☕️

#Design_Patterns
#Prototype_Design_Pattern

👉Check list

1️⃣Add a clone() method to the existing "product" hierarchy.

2️⃣Design a "registry" that maintains a cache of prototypical objects. The registry could be encapsulated in a new Factory class, or in the base class of the "product" hierarchy.

3️⃣Design a factory method that: may (or may not) accept arguments, finds the correct prototype object, calls clone() on that object, and returns the result.

4️⃣The client replaces all references to the new operator with calls to the factory method.

@javaCode☕️

#Design_Patterns
#Prototype_Design_Pattern

👉Rules of thumb

1️⃣Sometimes creational patterns are competitors: there are cases when either Prototype or Abstract Factory could be used properly. At other times they are complementary: Abstract Factory might store a set of Prototypes from which to clone and return product objects. Abstract Factory, Builder, and Prototype can use Singleton in their implementations.

2️⃣Abstract Factory classes are often implemented with Factory Methods, but they can be implemented using Prototype.

3️⃣Factory Method: creation through inheritance. Prototype: creation through delegation.

4️⃣Often, designs start out using Factory Method (less complicated, more customizable, subclasses proliferate) and evolve toward Abstract Factory, Prototype, or Builder (more flexible, more complex) as the designer discovers where more flexibility is needed.

5️⃣Prototype doesn't require subclassing, but it does require an "initialize" operation. Factory Method requires subclassing, but doesn't require Initialize.
Designs that make heavy use of the Composite and Decorator patterns often can benefit from Prototype as well.

6️⃣Prototype co-opts one instance of a class for use as a breeder of all future instances.

7️⃣Prototypes are useful when object initialization is expensive, and you anticipate few variations on the initialization parameters. In this context, Prototype can avoid expensive "creation from scratch", and support cheap cloning of a pre-initialized prototype.

8️⃣Prototype is unique among the other creational patterns in that it doesn't require a class – only an object. Object-oriented languages like Self and Omega that do away with classes completely rely on prototypes for creating new objects.

@javaCode☕️

#Design_Patterns

#Singleton_Design_Pattern

👉Intent

Ensure a class has only one instance, and provide a global point of access to it.
Encapsulated "just-in-time initialization" or "initialization on first use".

@javaCode☕️

#Design_Patterns

#Singleton_Design_Pattern

👉Problem

Application needs one, and only one, instance of an object. Additionally, lazy initialization and global access are necessary.

@javaCode☕️

#Design_Patterns
#Singleton_Design_Pattern

👉Discussion

Make the class of the single instance object responsible for creation, initialization, access, and enforcement. Declare the instance as a private static data member. Provide a public static member function that encapsulates all initialization code, and provides access to the instance.

The client calls the accessor function (using the class name and scope resolution operator) whenever a reference to the single instance is required.

Singleton should be considered only if all three of the following criteria are satisfied:

▪️Ownership of the single instance cannot be reasonably assigned

▪️Lazy initialization is desirable

▪️Global access is not otherwise provided for

If ownership of the single instance, when and how initialization occurs, and global access are not issues, Singleton is not sufficiently interesting.

The Singleton pattern can be extended to support access to an application-specific number of instances.

The "static member function accessor" approach will not support subclassing of the Singleton class. If subclassing is desired, refer to the discussion in the book.

Deleting a Singleton class/instance is a non-trivial design problem. See "To Kill A Singleton" by John Vlissides for a discussion.

@javaCode☕️

#Design_Patterns
#Singleton_Design_Pattern

👉Structure

Make the class of the single instance responsible for access and "initialization on first use". The single instance is a private static attribute. The accessor function is a public static method.

@javaCode☕️

#Design_Patterns
#Singleton_Design_Pattern

👉Example

The Singleton pattern ensures that a class has only one instance and provides a global point of access to that instance. It is named after the singleton set, which is defined to be a set containing one element. The office of the President of the United States is a Singleton. The United States Constitution specifies the means by which a president is elected, limits the term of office, and defines the order of succession. As a result, there can be at most one active president at any given time. Regardless of the personal identity of the active president, the title, "The President of the United States" is a global point of access that identifies the person in the office.

@javaCode☕️

#Design_Patterns
#Singleton_Design_Pattern

👉Check list

1️⃣Define a private static attribute in the "single instance" class.

2️⃣Define a public static accessor function in the class.

3️⃣Do "lazy initialization" (creation on first use) in the accessor function.

4️⃣Define all constructors to be protected or private.

5️⃣Clients may only use the accessor function to manipulate the Singleton.

@javaCode☕️