Visitor

The visitor design pattern is a way of separating an algorithm from an object structure on which it operates. A practical result of this separation is the ability to add new operations to existing object structures without modifying the structures. It is one way to follow the open/closed principle.

In essence, the visitor allows adding new virtual functions to a family of classes, without modifying the classes. Instead, a visitor class is created that implements all of the appropriate specialisations of the virtual function. The visitor takes the instance reference as input, and implements the goal through double dispatch.

Overview

What problems can the Visitor design pattern solve?
• It should be possible to define a new operation for (some) classes of an object structure without changing the classes.

When new operations are needed frequently and the object structure consists of many unrelated classes, it's inflexible to add new subclasses each time a new operation is required because "[..] distributing all these operations across the various node classes leads to a system that's hard to understand, maintain, and change."

What solution does the Visitor design pattern describe?
1. Define a separate (visitor) object that implements an operation to be performed on elements of an object structure.
2. Clients traverse the object structure and call a dispatching operation accept (visitor) on an element — that "dispatches" (delegates) the request to the "accepted visitor object". The visitor object then performs the operation on the element ("visits the element").

This makes it possible to create new operations independently from the classes of an object structure by adding new visitor objects.

Template method

The template method is a method in a superclass, usually an abstract superclass, and defines the skeleton of an operation in terms of a number of high-level steps. These steps are themselves implemented by additional helper methods in the same class as the template method.

Overview

This pattern has two main parts:

The "template method" is implemented as a method in a base class (usually an abstract class). This method contains code for the parts of the overall algorithm that are invariant. The template ensures that the overarching algorithm is always followed. In the template method, portions of the algorithm that may vary are implemented by sending self messages that request the execution of additional helper methods. In the base class, these helper methods are given a default implementation, or none at all (that is, they may be abstract methods).

Subclasses of the base class "fill in" the empty or "variant" parts of the "template" with specific algorithms that vary from one subclass to another. It is important that subclasses do not override the template method itself.

At run-time, the algorithm represented by the template method is executed by sending the template message to an instance of one of the concrete subclasses. Through inheritance, the template method in the base class starts to execute. When the template method sends a message to self requesting one of the helper methods, the message will be received by the concrete sub-instance. If the helper method has been overridden, the overriding implementation in the sub-instance will execute; if it has not been overridden, the inherited implementation in the base class will execute. This mechanism ensures that the overall algorithm follows the same steps every time, while allowing the details of some steps to depend on which instance received the original request to execute the algorithm.

Strategy

The strategy pattern (also known as the policy pattern) is a behavioral software design pattern that enables selecting an algorithm at runtime. Instead of implementing a single algorithm directly, code receives run-time instructions as to which in a family of algorithms to use.

Strategy lets the algorithm vary independently from clients that use it. Strategy is one of the patterns included in the influential book Design Patterns by Gamma et al. that popularized the concept of using design patterns to describe how to design flexible and reusable object-oriented software. Deferring the decision about which algorithm to use until runtime allows the calling code to be more flexible and reusable.

For instance, a class that performs validation on incoming data may use the strategy pattern to select a validation algorithm depending on the type of data, the source of the data, user choice, or other discriminating factors. These factors are not known until run-time and may require radically different validation to be performed. The validation algorithms (strategies), encapsulated separately from the validating object, may be used by other validating objects in different areas of the system (or even different systems) without code duplication.

State

The state pattern is a behavioral software design pattern Chain of responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template method, Visitor that allows an object to alter its behavior when its internal state changes. This pattern is close to the concept of finite-state machines. The state pattern can be interpreted as a strategy pattern, which is able to switch a strategy through invocations of methods defined in the pattern's interface.

The state pattern is used in computer programming to encapsulate varying behaviour for the same object , based on its internal state. This can be a cleaner way for an object to change its behavior at runtime without resorting to conditional statements and thus improve maintainability.

The state pattern is set to solve two main problems:
1. An object should change its behavior when its internal state changes.
2. State-specific behavior should be defined independently. That is, adding new states should not affect the behavior of existing states.

Implementing state-specific behavior directly within a class is inflexible because it commits the class to a particular behavior and makes it impossible to add a new state or change the behavior of an existing state later, independently from the class, without changing the class.

In this, the pattern describes two solutions:
• Define separate (state) objects that encapsulate state-specific behavior for each state. That is, define an interface (state) for performing state-specific behavior, and define classes that implement the interface for each state.
• A class delegates state-specific behavior to its current state object instead of implementing state-specific behavior directly.

This makes a class independent of how state-specific behavior is implemented. New states can be added by defining new state classes. A class can change its behavior at run-time by changing its current state object.

Observer pattern

The observer pattern is a behavioral software design pattern Chain of responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template method Visitor in which an object, named the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes , usually by calling one of their methods.

Which problems can the Observer design pattern solve?

The Observer pattern addresses the following problems:
1. A one-to-many dependency between objects should be defined without making the objects tightly coupled.
2. It should be ensured that when one object changes state, an open-ended number of dependent objects are updated automatically.
3. 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 (think of low-level kernel structures that execute thousands of times a second). 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.

What solution does the Observer design pattern describe?
• Define Subject and Observer objects.
• so that when a subject changes state, all registered observers are notified and updated automatically (and probably asynchronously).

The sole responsibility of a subject is to maintain a list of observers and to notify them of state changes by calling their update() operation. The responsibility of observers is to register (and unregister) themselves on a subject (to get notified of state changes) and to update their state (synchronize their state with the subject's state) when they are notified.

Memento

The memento pattern is a behavioural design pattern Chain of responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template method, Visitor that exposes the private internal state of an object. One example of how this can be used is to restore an object to its previous state (undo via rollback), another is versioning, another is custom serialization.

The memento pattern uses three objects: the originator, a caretaker and a memento. The originator is some object with an internal state. The caretaker is going to do something to the originator, but wants to be able to undo the change. The caretaker first asks the originator for a memento object. Then it does whatever operation (or sequence of operations) it was going to do. To roll back to the state before the operations, it returns the memento object to the originator. The memento object itself is an opaque object (one which the caretaker cannot, or should not, change). When using this pattern, care should be taken if the originator may change other objects or resources—the memento pattern operates on a single object.

What problems can the Memento design pattern solve?
1. The internal state of an object should be saved externally so that the object can be restored to this state later.
2. The object's encapsulation must not be violated.

The problem is that a well designed object is encapsulated so that its representation (data structure) is hidden inside the object and can't be accessed from outside the object.

What solution does the Memento design pattern describe? Make an object (originator) itself responsible for
• saving its internal state to a (memento) object and
• restoring to a previous state from a (memento) object.

Only the originator that created a memento is allowed to access it.

A client (caretaker) can request a memento from the originator (to save the internal state of the originator) and pass a memento back to the originator (to restore to a previous state).

Mediator

In software engineering, the mediator pattern defines an object that encapsulates how a set of objects interact. This pattern is considered to be a behavioural pattern Chain of responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template, method, Visitor due to the way it can alter the programme's running behavior.

With the mediator pattern, communication between objects is encapsulated within a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby reducing coupling.

Overview

What problems can the Mediator design pattern solve?
1. Tight coupling between a set of interacting objects should be avoided.
2. It should be possible to change the interaction between a set of objects independently.

Defining a set of interacting objects by accessing and updating each other directly is inflexible because it tightly couples the objects to each other and makes it impossible to change the interaction independently from (without having to change) the objects. And it stops the objects from being reusable and makes them hard to test.

What solution does the Mediator design pattern describe?
• Define a separate (mediator) object encapsulating the interaction between a set of objects.
• Objects delegate their interaction to a mediator object instead of interacting with each other directly.

The objects interact with each other indirectly through a mediator object that controls and coordinates the interaction. This makes the objects loosely coupled. They only refer to and know about their mediator object and have no explicit knowledge of each other.

Iterator

The iterator pattern is a behavioural design pattern Chain of responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template method, Visitor in which an iterator is used to traverse a container and access the container's elements. The iterator pattern decouples algorithms from containers.

For example, the hypothetical algorithm SearchForElement can be implemented generally using a specified type of iterator rather than implementing it as a container-specific algorithm. This allows SearchForElement to be used on any container that supports the required type of iterator.

Overview

What problems can the Iterator design pattern solve?
1. The elements of an aggregate object should be accessed and traversed without exposing its representation.
2. New traversal operations should be defined for an aggregate object without changing its interface.

What solution does the Iterator design pattern describe?
• Define a separate (iterator) object that encapsulates accessing and traversing an aggregate object.
• Clients use an iterator to access and traverse an aggregate without knowing its representation.

Different iterators can be used to access and traverse an aggregate in different ways.

Interpreter

The interpreter pattern is a behavioural design pattern Chain of responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template method, Visitor that specifies how to evaluate sentences in a language. The basic idea is to have a class for each symbol (terminal or nonterminal) in a specialised computer language. The syntax tree of a sentence in the language is an instance of the composite pattern and is used to evaluate (interpret) the sentence for a client.

Overview

What problems can the Interpreter design pattern solve?
1. A grammar for a simple language should be defined
2. so that sentences in the language can be interpreted.

When a problem occurs very often, it could be considered to represent it as a sentence in a simple language (Domain Specific Languages) so that an interpreter can solve the problem by interpreting the sentence.

What solution does the Interpreter design pattern describe?
• Define a grammar for a simple language by defining an Expression class hierarchy and implementing an interpret() operation.
• Represent a sentence in the language by an abstract syntax tree (AST) made up of Expression instances.
• Interpret a sentence by calling interpret() on the AST.

The Interpreter pattern doesn't describe how to build an abstract syntax tree. This can be done either manually by a client or automatically by a parser.

Command

In object-oriented programming, the command pattern is a behavioral design pattern Chain of responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template method, Visitor in which an object is used to encapsulate all information needed to perform an action or trigger an event at a later time.

Four terms always associated with the command pattern are command, receiver, invoker and client. A command object knows about the receiver and invokes a method of the receiver. Values for parameters of the receiver method are stored in the command. The receiver object to execute these methods is also stored in the command object by aggregation. The receiver then does the work when the execute() method in command is called. An invoker object knows how to execute a command, and optionally does bookkeeping about the command execution. The invoker does not know anything about a concrete command, it knows only about the command interface. Invoker object(s), command objects and receiver objects are held by a client object, the client decides which receiver objects it assigns to the command objects, and which commands it assigns to the invoker. The client decides which commands to execute at which points. To execute a command, it passes the command object to the invoker object.

Overview

Using the command design pattern can solve these problems:
1. Coupling the invoker of a request to a particular request should be avoided. That is, hard-wired requests should be avoided.
2. It should be possible to configure an object (that invokes a request) with a request.

Implementing (hard-wiring) a request directly into a class is inflexible because it couples the class to a particular request at compile-time, which makes it impossible to specify a request at run-time.

Using the command design pattern describes the following solution:
• Define separate (command) objects that encapsulate a request.
• A class delegates a request to a command object instead of implementing a particular request directly.

This enables one to configure a class with a command object that is used to perform a request. The class is no longer coupled to a particular request and has no knowledge of how the request is carried out.

Proxy

The proxy pattern is a strucutral patternadapter, bridge, composite, decorator, facade, flyweight, proxy , where a class functions as an interface to something else. The proxy could interface to anything: a network connection, a large object in memory, a file, or some other resource that is expensive or impossible to duplicate. In short, a proxy is a wrapper or agent object that is being called by the client to access the real serving object behind the scenes. For the client, usage of a proxy object is similar to using the real object, because both implement the same interface.

What problems can the Proxy design pattern solve?
1. The access to an object should be controlled.
2. Additional functionality should be provided when accessing an object.

When accessing sensitive objects, for example, it should be possible to check that clients have the needed access rights.

What solution does the Proxy design pattern describe?
• Define a separate Proxy object that
• can be used as substitute for another object (Subject) and
• implements additional functionality to control the access to this subject.

This makes it possible to work through a Proxy object to perform additional functionality when accessing a subject. For example, to check the access rights of clients accessing a sensitive object.

To act as substitute for a subject, a proxy must implement the Subject interface. Clients can't tell whether they work with a subject or its proxy.

Flyweight

The flyweight software design pattern is a structural pattern adapter, bridge, composite, decorator, facade, flyweight and proxy that refers to an object that minimises memory usage by sharing some of its data with other similar objects.

Overview

The flyweight pattern is useful when dealing with large numbers of objects with simple repeated elements that would use a large amount of memory if individually stored. It is common to hold shared data in external data structures and pass it to the objects temporarily when they are used.

A classic example are the data structures used representing characters in a word processor. Naively, each character in a document might have a glyph object containing its font outline, font metrics, and other formatting data. However, this would use hundreds or thousands of bytes of memory for each character. Instead, each character can have a reference to a glyph object shared by every instance of the same character in the document. This way, only the position of each character needs to be stored internally.

As a result, flyweight objects can:
1. store intrinsic state that is invariant, context-independent and shareable (for example, the code of character 'A' in a given character set)
2. provide an interface for passing in extrinsic state that is variant, context-dependent and can't be shared (for example, the position of character 'A' in a text document)

Clients can reuse Flyweight objects and pass in extrinsic state as necessary, reducing the number of physically created objects.

the Facade design pattern

The facade pattern (or façade) is a structural pattern Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy analogous to a facade in architecture; an object that serves as a front-facing interface masking more complex underlying or structural code. A facade can:

• improve the readability of a library by masking interaction with more complex components behind a single API
• provide a context-specific interface to more generic functionality
• serve as a launching point for a broader refactor of monolithic or tightly-coupled systems in favor of more loosely-coupled code

Developers often use the facade design pattern when a system is very complex or difficult to understand because the system has many interdependent classes or because its source code is unavailable. This pattern hides the complexities of the larger system and provides a simpler interface to the client. It typically involves a single wrapper class that contains a set of members required by the client.

Overview

Problems can the Facade design pattern solves

1. To make a complex subsystem easier to use, a simple interface should be provided for a set of interfaces in the subsystem.
2. The dependencies on a subsystem should be minimised.

A Facade is used when an easier or simpler interface to an underlying object is desired. Alternatively, an adapter can be used when the wrapper must respect a particular interface and must support polymorphic behaviour.

Decorator

The decorator pattern is a structural pattern Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy that allows behavior to be added to an individual object, dynamically, without affecting the behavior of other objects from the same class. The decorator pattern is often useful for adhering to the Single Responsibility Principle, as it allows functionality to be divided between classes with unique areas of concern. Decorator use can be more efficient than subclassing, because an object's behaviour can be augmented without defining an entirely new object.

Overview

What problems can it solve?
• Responsibilities should be added to (and removed from) an object dynamically at run-time.
• A flexible alternative to subclassing for extending functionality should be provided.

Define Decorator objects that
1. implement the interface of the extended (decorated) object (Component) transparently by forwarding all requests to it
2. perform additional functionality before/after forwarding a request.

This allows working with different Decorator objects to extend the functionality of an object dynamically at run-time.

Composite

The composite pattern is a partitioning design pattern, describing a group of objects that are treated the same way as a single instance of the same type of object . The intent of a composite is to "compose" objects into tree structures to represent part-whole hierarchies. Implementing the composite pattern lets clients treat individual objects and compositions uniformly.

Overview

What problems can the Composite design pattern solve?
• A part-whole hierarchy should be represented so that clients can treat part and whole objects uniformly.
• A part-whole hierarchy should be represented as tree structure.

What solution does the Composite design pattern describe?
1. Define a unified Component interface for both part (Leaf) objects and whole (Composite) objects.
2. Individual Leaf objects implement the Component interface directly, and Composite objects forward requests to their child components.

This enables clients to work through the Component interface to treat Leaf and Composite objects uniformly: Leaf objects perform a request directly, while Composite objects forward the request to their child components recursively downwards the tree structure. This makes client classes easier to implement, change, test and reuse.

Bridge Pattern

The bridge pattern is a design pattern used meant to "decouple an abstraction from its implementation so that the two can vary independently" . The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes.

When a class varies often, the features of object-oriented programming become very useful because changes to a program's code can be made easily with minimal prior knowledge about the program. The bridge pattern is useful when both the class and what it does vary often. The class itself can be thought of as the abstraction and what the class can do as the implementation. The bridge pattern can also be thought of as two layers of abstraction.

A Variant of this pattern is an implementation that can be decoupled even more by deferring the presence of the implementation to the point where the abstraction is utilized.

Overview

problems that the Bridge design pattern can solve
• An abstraction and its implementation should be defined and extended independently from each other.
• A compile-time binding between an abstraction and its implementation should be avoided so that an implementation can be selected at run-time.

What solution does the Bridge design pattern describe?
1. Separate an abstraction (Abstraction) from its implementation (Implementor) by putting them in separate class hierarchies.
2. Implement the Abstraction in terms of (by delegating to) an Implementor object.