The singleton pattern is probably the most widely used design pattern since the inception of Java. It is a simple pattern, easy to understand and to use. Sometimes it is used in excess, and in scenarios where it is not required. In such cases, the disadvantages of using it outweigh the advantages it brings. For this reason, the singleton is sometimes considered an anti-pattern. However, there are many scenarios where singletons are necessary.

As its name suggests, the singleton pattern is used to ensure that only a single instance of an object can be created. In addition to that, it also provides global access to that instance. The implementation of a singleton pattern is described in the following class diagram:

The implementation of the singleton pattern is very simple and consists of a single class. To ensure that the singleton instance is unique, all singleton...

As discussed in the previous chapter, inheritance is one of the fundamental concepts in object-oriented programming. Along with subtyping polymorphism, it gives us the is/a relationship. A Car object can be handled as a Vehicle object. A Truck object can be handled as a Vehicle object too. On one hand, this kind of abstraction makes our code thinner, because the same piece of code can handle operations for both Car and Truck objects. On the other hand, it gives us the option to extend our code to new types of Vehicle objects by simply adding new classes such as Bike and Van without modifying it.

When we deal with such scenarios, one of the trickiest parts is the creation of objects. In object-oriented programming, each object is instantiated using the constructor of the specific class, as shown in the following code:

Vehicle vehicle = new Car();

This piece...

The builder pattern serves the same purpose as the other creational patterns, but it does so in a different way and for different reasons. When developing complex applications, the code tends to become more complex. Classes tend to encapsulate more functionality and, at the same time, class structures become more complex. As the functionality grows, more scenarios need to be covered and, for these, different representations of classes are required.

When we have a complex class that we need to instantiate to different objects with different structures or different internal states, we can use separate classes to encapsulate the instantiation logic. These classes are called builders. Each time we need objects from the same class with a different structure, we can create another builder to create such instances.

The same concept can be used not only for classes for...

The prototype pattern is a pattern that seems more complicated than it really is. Practically, it is just a method to clone objects. Why would we need to clone objects when, these days, instantiating objects is not too costly in terms of performance? There are several situations in which it is required to clone objects that are already instantiated:

• When the creation of a new object relies on an external resource or a hardware-intensive operation
• When we need a copy of the same object with the same state without having to redo all of the operations to get to that state
• When we need an instance of an object without knowing to which concrete class it belongs

Let's look at the following class diagram:

In the prototype pattern, the following classes are involved:

• Prototype: This is the base class, or an interface that declares the clone() method that derived...

The instantiation of objects is one of the most costly operations in terms of performance. While in the past this could have been an issue, nowadays we shouldn't be concerned about it. However, when we deal with objects that encapsulate external resources, such as database connections, the creation of new objects becomes expensive.

The solution is to implement a mechanism that reuses and shares objects that are expensive to create. This solution is called the object pool pattern and it has the following structure:

The classes that are used in the object pool pattern are the following:

• ResourcePool: A class that encapsulates the logic to hold and manage a list of resources.
• Resource: A class that encapsulates a limited resource. The Resource classes are always referenced by the ResourcePool, so they will never be garbage collected as long as the ResourcePool...

In this chapter, we covered creational design patterns. We talked about variations of the singleton, factory, builder, prototype, and object pool patterns. All these patterns are used to instantiate new objects and give code flexibility and reusability while creating objects. In the next chapter, we will cover behavioral patterns. While creational patterns help us to manage the creation of objects, behavioral patterns provide an easy way to manage the behavior of objects.