Adapter

The adapter pattern is a structural pattern Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy (also known as wrapper, an alternative naming shared with the decorator pattern) that allows the interface of an existing class to be used as another interface.

The adapter design pattern solves problems like:
• How can a class be reused that does not have an interface that a client requires?
• How can classes that have incompatible interfaces work together?
• How can an alternative interface be provided for a class?

The adapter design pattern describes how to solve such problems:
1. Define a separate adapter class that converts the (incompatible) interface of a class (adaptee) into another interface (target) clients require.
2. Work through an adapter to work with (reuse) classes that do not have the required interface.

The key idea in this pattern is to work through a separate adapter that adapts the interface of an (already existing) class without changing it.

Singleton

The singleton creational pattern Abstract factory, Builder, Factory method, Prototype, Singleton restricts the instantiation of a class to one "single" instance so only one object is needed to coordinate actions across the system.

Overview

The singleton design pattern is one of the twenty-three well-known "Gang of Four" design patterns that describe how to solve recurring design problems to design flexible and reusable object-oriented software with the aim of making it easier to implement, change, test, and reuse objects.

The singleton design pattern solves problems by allowing it to:
1. Ensure that a class only has one instance
2. Easily access the sole instance of a class
3. Control its instantiation
4. Restrict the number of instances
5. Access a global variable

The singleton design pattern describes how to solve such problems:
• Hide the constructors of the class.
• Define a public static operation (getInstance()) that returns the sole instance of the class.

In essence, the singleton pattern forces it to be responsible for ensuring that it is only instantiated once. A hidden constructor-declared private or protected- ensures that the class can never be instantiated from outside the class. The public static operation can be accessed by using the class name and operation name, e.g., Singleton.getInstance().

Prototype

The prototype pattern is a creational design pattern Builder, Abstract factory, Factory method, Prototype, Singleton used when the type of objects to create is determined by a prototypical instance, cloned to produce new objects. This pattern is used to avoid subclasses of an object creator in the client application, like the factory method pattern does and to avoid the inherent cost of creating a new object in the standard way (e.g., using the 'new' keyword) when it is prohibitively expensive for a given application.

To implement the pattern, the client declares an abstract base class that specifies a pure virtual clone() method. Any class that needs a "polymorphic constructor" capability derives itself from the abstract base class, and implements the clone() operation.

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.

Overview

The prototype design pattern solves problems like:
• How can objects be created so that which objects to create can be specified at run-time?
• How can dynamically loaded classes be instantiated?

Creating objects directly within the class that requires the objects is inflexible because it commits the class to particular objects at compile-time and makes it impossible to specify which objects to create at run-time.

The prototype design pattern describes how to solve such problems:
1. Define a Prototype object that returns a copy of itself.
2. Create new objects by copying a Prototype object.

This enables configuration of a class with different Prototype objects, which are copied to create new objects. Prototype objects can be added and removed at run-time.

Factory Method

Factory method is a abstract factory, builder, factory method, prototype and singleton. creational pattern that uses factory methods to creat objects without specifying the exact class of the object being 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.

The Factory Method design pattern solves problems like:

• How can an object be created so that subclasses can redefine which class to instantiate?
• How can a class defer instantiation to subclasses?

The Factory Method design pattern describes how to solve such problems:

• Define a separate operation (factory method) for creating an object.
• Create an object by calling a factory method.

This enables writing of subclasses to change the way an object is created.

Definition

Defines an interface for creating an object, but let subclasses decide which class to instantiate. The Factory method lets a class defer instantiation it uses to subclasses.

The factory method pattern relies on inheritance, as object creation is delegated to subclasses that implement the factory method to create objects.

Builder

The builder pattern 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. By doing so, the same construction process can create different representations.

Overview

The Builder design pattern solves problems like:

• How can a class create different representations of a complex object?
• How can a class that includes creating a complex object be simplified?

Creating and assembling the parts of a complex object directly within a class is inflexible. It commits the class to creating a particular representation of the complex object and makes it impossible to change the representation later independently from (without having to change) the class.

The Builder design pattern describes how to solve such problems:

• Encapsulate creating and assembling the parts of a complex object in a separate Builder object.
• A class delegates object creation to a Builder object instead of creating the objects directly.

A class can delegate to different Builder objects to create different representations of a complex object.

Abstract Factory

The abstract factory pattern allows to encapsulate a set of individual factories with a common theme without specifying their concrete classes.

The essence of the Abstract Factory Pattern is to "Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

The client software would usually create 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 does not know (or care) which concrete objects it gets from each of these internal factories, since it uses only their generic interfaces. 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.

A factory is the location of a concrete class in the code at which objects are constructed. The intent in employing the pattern is to insulate the creation of objects from their usage and to create families of related objects without having to depend on their concrete classes. This allows for new derived types to be introduced with no change to the code that uses the base class.

Use of this pattern makes it possible to interchange concrete implementations without changing the code that uses them, even at runtime.

The Abstract Factory design pattern solves problems like:

• How can an application be independent of how its objects are created?
• How can a class be independent of how the objects it requires are created?
• How can families of related or dependent objects be created?

The Abstract Factory design pattern describes how to solve such problems:

Encapsulate object creation in a separate (factory) object. That is, define an interface (AbstractFactory) for creating objects, and implement the interface.

A class delegates object creation to a factory object instead of creating objects directly.

Chain of Responsibility

In design pattern, chain-of-responsibility pattern is a behavioral design pattern consisting of command objects and processing objects, each logic defining the types of command objects that it can handle; the rest are passed to the next processing object in the chain. A mechanism also adds new processing objects to the end of this chain.

This pattern promotes the idea of loose coupling.

The chain-of-responsibility pattern is nearly identical to the decorator pattern, the difference being that for the decorator, all classes handle the request, while for the chain of responsibility, exactly one of the classes in the chain handles the request .

Overview

The Chain of Responsibility design pattern is one of the twenty-three well-known GoF design patterns that describe common solutions to recurring design problems when designing flexible and reusable object-oriented software, that is, objects that are easier to implement, change, test, and reuse.

What problems can the Chain of Responsibility design pattern solve?

• Coupling the sender of a request to its receiver should be avoided.
• It should be possible that more than one receiver can handle a request.

Implementing a request directly within the class that sends the request is inflexible because it couples the class to a particular receiver and makes it impossible to support multiple receivers.

The solution that the Chain of Responsibility design pattern describes is for defining a chain of receiver objects having the responsibility, depending on run-time conditions, to either handle a request or forward it to the next receiver on the chain.

This enables us to send a request to a chain of receivers without having to know which one handles the request. The request gets passed along the chain until a receiver handles the request. The sender of a request is no longer coupled to a particular receiver.

Observer

The observer pattern is a software design pattern in which an object, the subject,keeps a list of its dependents, called observers, notifying them automatically of any state changes, usually by calling one of their methods.

It is mainly used for implementing distributed event handling systems, in "event driven" software, where the subject is usually named a "stream of events" or "stream source of events", while the observers are the "sinks of events". This pattern then perfectly suits any process where data arrives from some input that is not available to the CPU at startup, but instead arrives "at random" (HTTP requests, GPIO data, user input from keyboard/mouse/..., distributed databases and blockchains, ...). While not mandatory, most 'observers' implementations would use background threads listening for subject-events and other support mechanisms provided by the kernel (Linux epoll, ...).

Overview

The Observer design pattern is a behavioural pattern, among the twenty-three well-known "Gang of Four" design patterns describing how to solve recurring design challenges in order to design flexible and reusable object-oriented software, i.e. objects which are easier to implement, change, test, and reuse.

Which problems can the Observer design pattern solve?

The Observer pattern addresses the following problems:

A one-to-many dependency between objects should be defined without making the objects tightly coupled.

It should be ensured that when one object changes state, an open-ended number of dependent objects are updated automatically.

It should be possible that one object can notify an open-ended number of other objects.

Defining a one-to-many dependency between objects by defining one object (subject) that updates the state of dependent objects directly is inflexible because it couples the subject to particular dependent objects. Still, it can make sense from a performance point of view or if the object implementation is tightly coupled. Tightly coupled objects can be hard to implement in some scenarios, and hard to reuse because they refer to and know about (and how to update) many different objects with different interfaces. In other scenarios, tightly coupled objects can be a better option since the compiler will be able to detect errors at compile-time and optimize the code at the CPU instruction level.

Regressive Testing

Regression testing (rarely, non-regression testing) is re-running functional and non-functional tests to ensure that previously developed and tested software still performs after a change. If not, that would be called a regression.

Changes that may require regression testing include bug fixes, software enhancements, configuration changes, and even substitution of electronic components. As regression test suites tend to grow with each found defect, test automation is frequently involved. Sometimes a change impact analysis is performed to determine an appropriate subset of tests (non-regression analysis).