4. Behavioral design patterns

Behavioral patterns take care of effective communication and the assignment of responsibilities between objects.

Template Method ¶

Definition¶

Template Method is a behavioral design pattern that defines the skeleton of an algorithm in the superclass but lets subclasses override specific steps of the algorithm without changing its structure.

uml diagram

Implementation Details¶

The Abstract Class declares methods that act as steps of an algorithm, as well as the actual template method which calls these methods in a specific order. The steps may either be declared abstract or have some default implementation.
Concrete Classes can override all of the steps, but not the template method itself.

Pros and Cons¶

Pros¶

You can let clients override only certain parts of a large algorithm, making them less affected by changes that happen to other parts of the algorithm.
You can pull the duplicate code into a superclass.

Cons¶

Some clients may be limited by the provided skeleton of an algorithm.
You might violate the Liskov Substitution Principle by suppressing a default step implementation via a subclass.
Template methods tend to be harder to maintain the more steps they have.

Usage¶

Use the Template Method pattern when you want to let clients extend only particular steps of an algorithm, but not the whole algorithm or its structure.
Use the pattern when you have several classes that contain almost identical algorithms with some minor differences. As a result, you might need to modify all classes when the algorithm changes.

Mediator ¶

Definition¶

Mediator is a behavioral design pattern that lets you reduce chaotic dependencies between objects. The pattern restricts direct communications between the objects and forces them to collaborate only via a mediator object.

uml diagram

Implementation Details¶

Components are various classes that contain some business logic. Each component has a reference to a mediator, declared with the type of the mediator interface. The component isn’t aware of the actual class of the mediator, so you can reuse the component in other programs by linking it to a different mediator.
The Mediator interface declares methods of communication with components, which usually include just a single notification method. Components may pass any context as arguments of this method, including their own objects, but only in such a way that no coupling occurs between a receiving component and the sender’s class.
Concrete Mediators encapsulate relations between various components. Concrete mediators often keep references to all components they manage and sometimes even manage their lifecycle.
Components must not be aware of other components. If something important happens within or to a component, it must only notify the mediator. When the mediator receives the notification, it can easily identify the sender, which might be just enough to decide what component should be triggered in return.
From a component’s perspective, it all looks like a total black box. The sender doesn’t know who’ll end up handling its request, and the receiver doesn’t know who sent the request in the first place.

Pros and Cons¶

Pros¶

Single Responsibility Principle. You can extract the communications between various components into a single place, making it easier to comprehend and maintain.
Open/Closed Principle. You can introduce new mediators without having to change the actual components.
You can reduce coupling between various components of a program.
You can reuse individual components more easily.

Cons¶

Over time a mediator can evolve into a God Object.

Usage¶

Use the Mediator pattern when it’s hard to change some of the classes because they are tightly coupled to a bunch of other classes.
Use the pattern when you can’t reuse a component in a different program because it’s too dependent on other components.
Use the Mediator when you find yourself creating tons of component subclasses just to reuse some basic behavior in various contexts.

Chain of Responsibility ¶

Definition¶

Chain of Responsibility is a behavioral design pattern that lets you pass requests along a chain of handlers. Upon receiving a request, each handler decides either to process the request or to pass it to the next handler in the chain. uml diagram

Implementation Details¶

The Handler declares the interface, common for all concrete handlers. It usually contains just a single method for handling requests, but sometimes it may also have another method for setting the next handler on the chain.
The Base Handler is an optional class where you can put the boilerplate code that’s common to all handler classes.
Usually, this class defines a field for storing a reference to the next handler. The clients can build a chain by passing a handler to the constructor or setter of the previous handler. The class may also implement the default handling behavior: it can pass execution to the next handler after checking for its existence.
Concrete Handlers contain the actual code for processing requests. Upon receiving a request, each handler must decide whether to process it and, additionally, whether to pass it along the chain.
Handlers are usually self-contained and immutable, accepting all necessary data just once via the constructor.
The Client may compose chains just once or compose them dynamically, depending on the application’s logic. Note that a request can be sent to any handler in the chain—it doesn’t have to be the first one.

Pros and Cons¶

Pros¶

You can control the order of request handling.
Single Responsibility Principle. You can decouple classes that invoke operations from classes that perform operations.
Open/Closed Principle. You can introduce new handlers into the app without breaking the existing client code.

Cons¶

Some requests may end up unhandled.

Usage¶

Use the Chain of Responsibility pattern when your program is expected to process different kinds of requests in various ways, but the exact types of requests and their sequences are unknown beforehand.
Use the pattern when it’s essential to execute several handlers in a particular order.
Use the CoR pattern when the set of handlers and their order are supposed to change at runtime.

Observer ¶

Definition¶

Observer is a behavioral design pattern that lets you define a subscription mechanism to notify multiple objects about any events that happen to the object they’re observing. uml diagram

Implementation Details¶

The Publisher issues events of interest to other objects. These events occur when the publisher changes its state or executes some behaviors. Publishers contain a subscription infrastructure that lets new subscribers join and current subscribers leave the list.
When a new event happens, the publisher goes over the subscription list and calls the notification method declared in the subscriber interface on each subscriber object.
The Subscriber interface declares the notification interface. In most cases, it consists of a single update method. The method may have several parameters that let the publisher pass some event details along with the update.
Concrete Subscribers perform some actions in response to notifications issued by the publisher. All of these classes must implement the same interface so the publisher isn’t coupled to concrete classes.
Usually, subscribers need some contextual information to handle the update correctly. For this reason, publishers often pass some context data as arguments of the notification method. The publisher can pass itself as an argument, letting subscriber fetch any required data directly.
The Client creates publisher and subscriber objects separately and then registers subscribers for publisher updates.

Pros and Cons¶

Pros¶

Open/Closed Principle. You can introduce new subscriber classes without having to change the publisher’s code (and vice versa if there’s a publisher interface).
You can establish relations between objects at runtime.

Cons¶

Subscribers are notified in random order.

Usage¶

Use the Observer pattern when changes to the state of one object may require changing other objects, and the actual set of objects is unknown beforehand or changes dynamically.
Use the pattern when some objects in your app must observe others, but only for a limited time or in specific cases.

Strategy ¶

Definition¶

Strategy is a behavioral design pattern that lets you define a family of algorithms, put each of them into a separate class, and make their objects interchangeable. uml diagram

Implementation Details¶

The Context maintains a reference to one of the concrete strategies and communicates with this object only via the strategy interface.
The Strategy interface is common to all concrete strategies. It declares a method the context uses to execute a strategy.
Concrete Strategies implement different variations of an algorithm the context uses.
The context calls the execution method on the linked strategy object each time it needs to run the algorithm. The context doesn’t know what type of strategy it works with or how the algorithm is executed.
The Client creates a specific strategy object and passes it to the context. The context exposes a setter which lets clients replace the strategy associated with the context at runtime.

Pros and Cons¶

Pros¶

You can swap algorithms used inside an object at runtime.
You can isolate the implementation details of an algorithm from the code that uses it.
You can replace inheritance with composition.
Open/Closed Principle. You can introduce new strategies without having to change the context.

Cons¶

If you only have a couple of algorithms and they rarely change, there’s no real reason to overcomplicate the program with new classes and interfaces that come along with the pattern.
Clients must be aware of the differences between strategies to be able to select a proper one.
A lot of modern programming languages have functional type support that lets you implement different versions of an algorithm inside a set of anonymous functions. Then you could use these functions exactly as you’d have used the strategy objects, but without bloating your code with extra classes and interfaces.

Usage¶

Use the Strategy pattern when you want to use different variants of an algorithm within an object and be able to switch from one algorithm to another during runtime.
Use the Strategy when you have a lot of similar classes that only differ in the way they execute some behavior.
Use the pattern to isolate the business logic of a class from the implementation details of algorithms that may not be as important in the context of that logic.
Use the pattern when your class has a massive conditional statement that switches between different variants of the same algorithm.

Command ¶

Definition¶

Command is a behavioral design pattern that turns a request into a stand-alone object that contains all information about the request. This transformation lets you pass requests as a method arguments, delay or queue a request’s execution, and support undoable operations. uml diagram

Implementation Details¶

The Sender class (aka invoker) is responsible for initiating requests. This class must have a field for storing a reference to a command object. The sender triggers that command instead of sending the request directly to the receiver. Note that the sender isn’t responsible for creating the command object. Usually, it gets a pre-created command from the client via the constructor.
The Command interface usually declares just a single method for executing the command.
Concrete Commands implement various kinds of requests. A concrete command isn’t supposed to perform the work on its own, but rather to pass the call to one of the business logic objects. However, for the sake of simplifying the code, these classes can be merged.
Parameters required to execute a method on a receiving object can be declared as fields in the concrete command. You can make command objects immutable by only allowing the initialization of these fields via the constructor.
The Receiver class contains some business logic. Almost any object may act as a receiver. Most commands only handle the details of how a request is passed to the receiver, while the receiver itself does the actual work.
The Client creates and configures concrete command objects. The client must pass all of the request parameters, including a receiver instance, into the command’s constructor. After that, the resulting command may be associated with one or multiple senders.

Pros and Cons¶

Pros¶

Single Responsibility Principle. You can decouple classes that invoke operations from classes that perform these operations.
Open/Closed Principle. You can introduce new commands into the app without breaking existing client code.
You can implement undo/redo.
You can implement deferred execution of operations.
You can assemble a set of simple commands into a complex one.

Cons¶

The code may become more complicated since you’re introducing a whole new layer between senders and receivers.

Usage¶

Use the Command pattern when you want to parametrize objects with operations.
Use the Command pattern when you want to queue operations, schedule their execution, or execute them remotely.
Use the Command pattern when you want to implement reversible operations.

State ¶

Definition¶

State is a behavioral design pattern that lets an object alter its behavior when its internal state changes. It appears as if the object changed its class. uml diagram

Implementation Details¶

Context stores a reference to one of the concrete state objects and delegates to it all state-specific work. The context communicates with the state object via the state interface. The context exposes a setter for passing it a new state object.
The State interface declares the state-specific methods. These methods should make sense for all concrete states because you don’t want some of your states to have useless methods that will never be called.
Concrete States provide their own implementations for the state-specific methods. To avoid duplication of similar code across multiple states, you may provide intermediate abstract classes that encapsulate some common behavior.
State objects may store a backreference to the context object. Through this reference, the state can fetch any required info from the context object, as well as initiate state transitions.
Both context and concrete states can set the next state of the context and perform the actual state transition by replacing the state object linked to the context.

Pros and Cons¶

Pros¶

Single Responsibility Principle. Organize the code related to particular states into separate classes.
Open/Closed Principle. Introduce new states without changing existing state classes or the context.
Simplify the code of the context by eliminating bulky state machine conditionals.

Cons¶

Applying the pattern can be overkill if a state machine has only a few states or rarely changes.

Usage¶

Use the State pattern when you have an object that behaves differently depending on its current state, the number of states is enormous, and the state-specific code changes frequently.
Use the pattern when you have a class polluted with massive conditionals that alter how the class behaves according to the current values of the class’s fields.
Use State when you have a lot of duplicate code across similar states and transitions of a condition-based state machine.

Visitor ¶

Definition¶

Visitor is a behavioral design pattern that lets you separate algorithms from the objects on which they operate.

uml diagram

Implementation Details¶

The Visitor interface declares a set of visiting methods that can take concrete elements of an object structure as arguments. These methods may have the same names if the program is written in a language that supports overloading, but the type of their parameters must be different.
Each Concrete Visitor implements several versions of the same behaviors, tailored for different concrete element classes.
The Element interface declares a method for “accepting” visitors. This method should have one parameter declared with the type of the visitor interface.
Each Concrete Element must implement the acceptance method. The purpose of this method is to redirect the call to the proper visitor’s method corresponding to the current element class. Be aware that even if a base element class implements this method, all subclasses must still override this method in their own classes and call the appropriate method on the visitor object.
The Client usually represents a collection or some other complex object (for example, a Composite tree). Usually, clients aren’t aware of all the concrete element classes because they work with objects from that collection via some abstract interface.

Pros and Cons¶

Pros¶

Open/Closed Principle. You can introduce a new behavior that can work with objects of different classes without changing these classes.
Single Responsibility Principle. You can move multiple versions of the same behavior into the same class.
A visitor object can accumulate some useful information while working with various objects. This might be handy when you want to traverse some complex object structure, such as an object tree, and apply the visitor to each object of this structure.

Cons¶

You need to update all visitors each time a class gets added to or removed from the element hierarchy.
Visitors might lack the necessary access to the private fields and methods of the elements that they’re supposed to work with.

Usage¶

Use the Visitor when you need to perform an operation on all elements of a complex object structure (for example, an object tree).
Use the Visitor to clean up the business logic of auxiliary behaviors.
Use the pattern when a behavior makes sense only in some classes of a class hierarchy, but not in others.

Iterator ¶

Definition¶

Iterator is a behavioral design pattern that lets you traverse elements of a collection without exposing its underlying representation (list, stack, tree, etc.). uml diagram

Implementation Details¶

The Iterator interface declares the operations required for traversing a collection: fetching the next element, retrieving the current position, restarting iteration, etc.
Concrete Iterators implement specific algorithms for traversing a collection. The iterator object should track the traversal progress on its own. This allows several iterators to traverse the same collection independently of each other.
The Collection interface declares one or multiple methods for getting iterators compatible with the collection. Note that the return type of the methods must be declared as the iterator interface so that the concrete collections can return various kinds of iterators.
Concrete Collections return new instances of a particular concrete iterator class each time the client requests one.
The Client works with both collections and iterators via their interfaces. This way the client isn’t coupled to concrete classes, allowing you to use various collections and iterators with the same client code.
Typically, clients don’t create iterators on their own, but instead get them from collections. Yet, in certain cases, the client can create one directly; for example, when the client defines its own special iterator.

Pros and Cons¶

Pros¶

Single Responsibility Principle. You can clean up the client code and the collections by extracting bulky traversal algorithms into separate classes.
Open/Closed Principle. You can implement new types of collections and iterators and pass them to existing code without breaking anything.
You can iterate over the same collection in parallel because each iterator object contains its own iteration state.
For the same reason, you can delay an iteration and continue it when needed.

Cons¶

Applying the pattern can be an overkill if your app only works with simple collections.
Using an iterator may be less efficient than going through elements of some specialized collections directly.

Usage¶

Use the Iterator pattern when your collection has a complex data structure under the hood, but you want to hide its complexity from clients (either for convenience or security reasons).
Use the pattern to reduce duplication of the traversal code across your app.
Use the Iterator when you want your code to be able to traverse different data structures or when types of these structures are unknown beforehand.

Interpreter ¶

Definition¶

Interpreter is a behavioral design pattern that is used to defines a grammatical representation for a language and provides an interpreter to deal with this grammar. uml diagram

Implementation Details¶

Client sends Context to Abstract Expression.
Terminal Expression evaluates context and returns
Nonterminal Expression performs "parrent" functionality. Then delegates to its children.

Pros and Cons¶

Pros¶

The interpreter design pattern is great for relatively simple grammar interpretation, which doesn’t need to evolve and extend much.

Cons¶

When the grammar is getting more complex, it becomes harder to maintain.

Usage¶

Memento ¶

Definition¶

Memento is a behavioral design pattern that lets you save and restore the previous state of an object without revealing the details of its implementation. uml diagram

Implementation Details¶

The Originator class can produce snapshots of its own state, as well as restore its state from snapshots when needed.
The Memento is a value object that acts as a snapshot of the originator’s state. It’s a common practice to make the memento immutable and pass it the data only once, via the constructor.
The Caretaker knows not only “when” and “why” to capture the originator’s state, but also when the state should be restored.
A caretaker can keep track of the originator’s history by storing a stack of mementos. When the originator has to travel back in history, the caretaker fetches the topmost memento from the stack and passes it to the originator’s restoration method.
In this implementation, the memento class is nested inside the originator. This lets the originator access the fields and methods of the memento, even though they’re declared private. On the other hand, the caretaker has very limited access to the memento’s fields and methods, which lets it store mementos in a stack but not tamper with their state.

Pros and Cons¶

Pros¶

You can produce snapshots of the object’s state without violating its encapsulation.
You can simplify the originator’s code by letting the caretaker maintain the history of the originator’s state.

Cons¶

The app might consume lots of RAM if clients create mementos too often.
Caretakers should track the originator’s lifecycle to be able to destroy obsolete mementos.
Most dynamic programming languages, such as PHP, Python and JavaScript, can’t guarantee that the state within the memento stays untouched.

Usage¶

Use the Memento pattern when you want to produce snapshots of the object’s state to be able to restore a previous state of the object.
Use the pattern when direct access to the object’s fields/getters/setters violates its encapsulation.