Design Patterns

Design patterns provide general solutions to software design problems we find in real-world application development.

Before starting with design patterns let's understand what the meaning of design patterns and why they are useful in software programming/architecture.

"Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice." - Christopher Alexander, A Pattern Language.

It is important to understand design patterns rather than memorizing their classes, methods and properties. First identify the software design problem then see how to address these problems using design patterns and determine the best suited design problem to solve the problem.

There are 23 design patterns, also known as Gang of Four (GoF) design patterns. The Gang of Four are the authors of the book, "Design Patterns: Elements of Reusable Object Oriented Software".

Creational Design Pattern

In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.

Simple Factory

Simple Factory Pattern returns an instance of one of several possible classes depending on the type of data provided. It is quite common to return a common parent class and common methods, but each may perform a task differently or optimize for different data or behaviors.

Factory Method

The factory method pattern is a creational pattern that uses factory methods to deal with the problem of creating objects without having to specify the exact class of the object that will be created. This is done by creating objects by calling a factory method—either specified in an interface and implemented by child classes, or implemented in a base class and optionally overridden by derived classes—rather than by calling a constructor.

Abstract Factory

The abstract factory pattern provides a way to encapsulate a group of individual factories that have a common theme without specifying their concrete classes. In normal usage, the client software creates a concrete implementation of the abstract factory and then uses the generic interface of the factory to create the concrete objects that are part of the theme. The client doesn't know or care which concrete objects it gets from each of these internal factories, since it uses only the generic interfaces of their products. This pattern separates the details of implementation of a set of objects from their general usage and relies on object composition, as object creation is implemented in methods exposed in the factory interface.

In simple words, It provides an interface for creating families of related or dependent objects without specifying their concrete classes.

Builder

The Builder is a design pattern designed to provide a flexible solution to various object creation problems in object-oriented programming. The intent of the Builder design pattern is to separate the construction of a complex object from its representation.

In simple words, separating the construction of a complex object from its representation so that the same construction process can create different representations.

Prototype

The prototype pattern is a creational design pattern in software development. It is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects.

In simple words, specifying the kind of objects to create using a prototypical instance, and create new objects by copying this prototype.

Singleton

The singleton pattern is a software design pattern that restricts the instantiation of a class to one single instance. This is useful when exactly one object is needed to coordinate actions across the system.

Note

We should not use Design Pattern just because it is a Design Pattern as no one should follow the best practice just because it is a best practice.