Chapter 5: Behavioral Design Patterns
In this chapter, we will describe and analyze behavioral design patterns, which is the last category in the list of classical patterns. Behavioral design patterns try to solve the problem of assigning the precise responsibilities between objects in a way that is both decoupled and cohesive. You want to maintain the right balance between those two concepts so that the clients that interface with the objects won't have to know their internal connections.
In this chapter, we are going to cover the following main topics:
- Behavioral design patterns
- The Strategy pattern
- Chain of Responsibility
- The Command pattern
- The Iterator pattern
- The Mediator pattern
- The Observer pattern
- The Memento pattern
- The State pattern
- The Template method pattern
- The Visitor pattern
By the end of this chapter, you will have amassed all the knowledge and skills required to make use of behavioral design patterns in your programs. You will have identified the criteria of their use and their pros and cons and have a solid understanding of their implementation details.
Technical requirements
The code bundle for this chapter is available on GitHub here:
https://github.com/PacktPublishing/TypeScript-4-Design-Patterns-and-Best-Practices/tree/main/chapters/chapter-5_Behavioral_Design_Patterns
Behavioral design patterns
With behavioral design patterns, you define abstractions that deal with relationships and the responsibilities between objects. You want to measure and manage how and when two or more objects can communicate with each other by message passing or direct references.
Often, you cannot merely obtain certain object references and call their methods, but you would like to use their functionality. Or you may have diverse ways to define the behavior of an object but you don't want to hardcode many switch statements or draft repetitive code.
The solution to these aforementioned problems is to define helper classes and interfaces that encapsulate this object's behavior and use them according to each occasion. By utilizing the behavioral patterns, you gain several benefits, including increased flexibility, low coupling, and reusability.
I will explain what I mean in greater detail as we look at these patterns, starting with the Chain of Responsibility.
The Strategy pattern?
The Strategy pattern represents a pattern that deals with encapsulating modified algorithms in an interface and making them interchangeable. This means you have an interface that represents a specific process or business case and you interchange concrete implementations at runtime so that you can change its behavior.
This pattern conceptually represents the simplest abstraction because it's essentially an interface that accepts different implementors at runtime. The only complexity you need to consider is how and when to switch between the strategies depending on the current context.
We will explain when to use this pattern next.
When to use the Strategy pattern
You can use the Strategy pattern whenever you see the following patterns:
- You have different variants of an algorithm and you want to interchange them at runtime: The variants of the algorithm might try different paths or conditions and you want the application to be able to switch between them based on some criteria. For example, when you want to calculate taxes for an individual, you may apply different strategies based on the individual's marital status, income, or any disabilities they have. You can create different strategies based on their current state.
- You want to encapsulate different behaviors in different classes but with the same interface: You have different algorithmic strategies that perform the same operation differently but you want to expose them under a single interface.
Using this pattern, you demonstrate the flexibility to define multiple implementations that follow some specific behavior and have the client or another service accept their common interface.
Based on their business logic or any specific configuration they have, they can pass on the correct Strategy object to gain the best results. This avoids having multiple switch or if statements in the code as you will exercise the power of polymorphism to alter the behavior. Let's see what the UML class diagram looks like for this pattern.
UML class diagram
In its simplest form, the Strategy pattern is just an interface with multiple implementors. You also have a context object that controls the logic of setting and evaluating the current strategy. This is what it looks like in UML:
Figure 5.1 – The Strategy pattern
BillingContext is the object that the client uses to resolve strategies. This object will encapsulate the logic of switching the different objects via the common BillingStrategy interface. We implement two different concrete strategies that implement this interface for flexibility.
Classic implementation
We showcase the implementation of this pattern based on the previous class diagram:
interface BillingStrategy {
calculate(): void;
}
class ConcreteBillingStrategyA implements BillingStrategy {
calculate(): void {
console.log("Calculating bill using first strategy");
}
}
class ConcreteBillingStrategyB implements BillingStrategy {
calculate(): void {
console.log("Calculating bill using second strategy");
}
}
class BillingContext {
constructor(private strategy: BillingStrategy) {}
setStrategy(strategy: BillingStrategy) {
this.strategy = strategy;
}
calculateBill(): void {
this.strategy.calculate();
}
}
Both the ConcreteBillingStrategyB and ConcreteBillingStrategyA classes implement the BillingStrategy interface that is used in the BillingContext class. It uses basic polymorphism to assign a new strategy either in the constructor or by using the setStrategy method. The call to the calculateBill method executes the current strategy.
Testing
The most fundamental test you can write for this pattern is to verify that each Strategy object performs as expected. For example, if you utilize two different strategies for calculating employee payments based on whether they have a bonus or not, you might check whether the calculation is correct without bonuses and with bonuses.
Additionally, you may want to test the logic that determines which strategy is applied internally depending on the context. You may want to add test cases that trigger the setStrategy method and verify that the correct strategy is used.
Criticism of this pattern
Of course, when using this pattern, you will need to have some substantial algorithms that make sense and not copy each other. Ideally, you want to have at least three or more strategies in place and know when to use them. Otherwise, you can do better with just an if statement or using a lambda function as a callback parameter when executing the algorithm.
Other than that, because of the simplicity of this pattern, you will find lots of cases where you can apply it in practical terms. Let's explore some real-world examples next.
Real-world use cases
This pattern is very popular in auth frameworks where you want to define multiple strategies for authentication. For example, we can inspect the code base of the nuxt-auth module, which is a Vue.js framework for developing web applications. In the type definition of this module for the provider, we can see the addAuthorize function:
https://github.com/nuxt-community/auth-module/blob/5a3c3a8a53195618923726b70f19b2ee8336b333/src/utils/provider.ts
The code accepts a StrategyOptions type, which can be several different types of auth strategies based on the OAuth framework. It then defines multiple auth strategies in the providers section for authenticating with GitHub, Facebook, Google, and other OAuth providers:
https://github.com/nuxt-community/auth-module/tree/75c20e64cc2bb8d4db7d7fc772432132a1d9e417/src/providers
Frameworks such as Passport.js work similarly. They define multiple authentication strategies for each provider.
We explore the basic concepts of the Chain of Responsibility pattern next.
Chain of Responsibility
Chain of Responsibility is a pattern that allows you to have a list of classes perform certain operations on a particular object in a series of processing events. The main idea here is to establish a chain of handlers that take an object as part of a request, perform some operation, and then pass on the object to the next handler.
An analogy of this pattern is where you have a group of friends and you pass along a message on a piece of paper. Each one of you has a chance to write something or change the message completely. At the end of the chain, you announce the final response.
The main benefit of this pattern is to avoid coupling all the logic into one function or a class and instead give the chance to several middleware handlers to employ their own distinct behaviors. You can say this pattern resembles a list of Decorator functions, each decorating the same object as it passes along the list.
When to use Chain of Responsibility?
You want to use the Chain of Responsibility to add several dynamic elements to a class or an object. More specifically, you want to use this pattern in the following instances:
- You have more than one Decorator object that handles a request before sending back a response: This pattern works well when you have more than one distinct handler class but are also trying to avoid using multiple Decorator patterns. You want to have the handlers perform distinct and unique functions before passing the request handler on to the next handler in the chain.
- You can add or remove items from the chain dynamically: This pattern is also useful when customizing which handlers to use and configuring the application at runtime. For example, say you have a handler that catches any errors in a request and you link the handler with another handler that logs the details of the request in that order.
Using this pattern provides several benefits with decoupling, as it provides a way of having the two objects connected to each other but without any hard dependencies. If you change one object, it will not affect the other and vice versa. You will see the UML class diagram of this pattern next.
UML class diagram
The main class model of this pattern is the Request object. This is passed along the chain and gets transformed based on the handlers attached to that chain. Here is an example visualization:
Figure 5.2 – Request object
Then, you will need to attach the chain of handlers that will process this Request object. This is done by having an interface or abstract class RequestHandler that each concrete handler will implement:
Figure 5.3 – Chain of Responsibility
In the preceding diagram, you can see that both the ConcreteHandler classes are chained together. One has a reference to the next one and they are also both composites. Then the client uses the root of the RequestHandler chain, namely ConcreteHandlerA, and calls the handle method. This will subsequently call the handle method of ConcreteHandlerB before ending the chain of handlers.
Now that you have seen the class diagram, you will learn how to implement it in TypeScript.
Classic implementation
If you were to implement this pattern, you would need to figure out the details of the Request object. You want to design it in a way that is easy to access its fields to perform additional actions on top of it. We define the Request object, for example, as follows:
ChainOfResponsibility.ts
interface IRequest {
getOrigin(): string;
getParams(): Map<string, string>;
}
class HTTPRequest implements IRequest {
constructor(private origin: string, private params:
Map<string, string>) {}
getOrigin(): string {
return this.origin;
}
getParams(): Map<string, string> {
return this.params;
}
}
The concrete HTTPRequest class represents the object that we pass along the Chain of Responsibility as a handler parameter. The actual chain is defined in the RequestHandler interface as follows:
ChainOfResponsibility.ts
abstract class RequestHandler {
constructor(protected next: RequestHandler | null) {}
handleRequest(request: IRequest) {
if (this.next !== null) {
this.next.handleRequest(request);
}
}
}
This abstract class represents the base request handler object that processes the requests in order. You now want to define at least two concrete implementations as follows:
ChainOfResponsibility.ts
class LogRequestHandler extends RequestHandler {
handleRequest(request: IRequest) {
console.log(
'Request with origin: ${request.getOrigin()} handled
by LogRequestHandler'
);
if (this.next !== null) {
this.next.handleRequest(request);
}
}
}
class EmailRequestHandler extends RequestHandler {
handleRequest(request: IRequest) {
console.log(
'Request with origin: ${request.getOrigin()} handled
by EmailRequestHandler'
);
if (this.next !== null) {
this.next.handleRequest(request);
}
}
}
The preceding classes extend the base RequestHandler class and perform actions on the Request object that is passed as a parameter. Then, the client only has to create this chain of handlers and pass an instance of the Request object:
const req = new HTTPRequest("localhost", new Map().set("q", "searchTerm"));
new LogRequestHandler(new EmailRequestHandler(null)).handleRequest(req);
// Request with origin: localhost handled by LogRequestHandler
// Request with origin: localhost handled by EmailRequestHandler
As you can see in the highlighted code, we wrap multiple handlers just like the Decorator pattern but we do not pass the request object as a parameter in the handleRequest method. Each chain handler will be called based on the order that it was attached to the list. Let's learn how to test this pattern next.
Testing
When writing test cases for this pattern, you want to check that each handler performs as expected when passing a Request object. Additionally, you want to make sure that the Request object is initialized with the correct state. Take the following example:
ChainOfResponsibility.test.ts
import { HTTPRequest, LogRequestHandler } from "./ChainOfResponsibility";
const spy = jest.spyOn(console, "log").mockImplementation();
afterAll(() => {
spy.mockRestore();
});
test("HTTPRequest", () => {
const req = new HTTPRequest("localhost", new
Map().set("q", "searchTerm"));
expect(req.getOrigin()).toBe("localhost");
expect(req.getParams()).toEqual(new Map().set("q",
"searchTerm"));
});
test("LogRequestHandler", () => {
const req = new HTTPRequest("localhost", new
Map().set("q", "searchTerm"));
const requestHandler = new LogRequestHandler(null);
requestHandler.handleRequest(req);
expect(spy).toHaveBeenCalledTimes(1);
});
You can run the test case for this file with the following command:
npm run test -- chapters/chapter-5_Behavioral_Design_Patterns/ChainOfResponsibility.test.ts
In the code example, the spy object mocks a global console object method and can be used to verify that when running the chain, this method was called. We mention some of the criticisms of this pattern next.
Criticisms of this pattern
If you utilize this pattern, you will recognize some of the faults of the Decorator pattern. You can see that this pattern augments the problem. If you link several handlers in a particular order, you may end up breaking the chain if you are not careful. This is particularly the case for unhandled promises or failed requests. You will need to wrap a try-catch clause somewhere just to prevent errors from propagating and breaking the flow.
Real-world use case
One good real-world use case of this pattern is in Express.js middleware handlers. Those are functions that have access to the request and response objects as part of the application's HTTP handling workflow.
You can see an example implementation of this pattern by inspecting the handle method here: https://github.com/expressjs/express/blob/master/lib/application.js#L158.
In this method, it retrieves the internal instance of router and calls the route's handle method, which subsequently triggers the chain of handlers:
var router = this._router;
router.handle(req, res, done);
In this case, router represents the RequestHandler object. Each handler is registered in the application by using the app.use method, which adds more handlers to the chain. Typically, you pre-register those handlers before starting the server to listen to requests, but this is not a limitation as you can do it dynamically as well.
As you've understood the basic principles of this pattern in practice, you will now learn about the next pattern on the list, which is the Command pattern.
The Command pattern
The Command pattern deals with creating special request objects that can be passed as parameters to receiver objects. The main idea of this pattern is that you want to separate a request action from handling each request in a way that both the request and receiver objects are decoupled. For instance, say you create an object that contains all the information necessary to perform actions such as triggering notifications or emails. This object will contain information such as the receiver's email address, name, or title. The receiver merely knows how to process the commands and employs the appropriate handler depending on the type of command. This way, you promote the single-responsibility principle, which is part of the SOLID principles, as you separate the responsibilities of the classes that perform actions and the classes that create actions.
An analogy of this pattern is where you have a microwave with buttons that represent actions. When you press a button for warming your food, it starts warming. If you want to stop the microwave, there is a different command for that as well.
When to use the Command pattern?
You want to use this pattern when you have to consider the following criteria:
- To separate request objects from handlers: Say you want to separate and encapsulate all the information in a request object. Then, you send this object to a handler that knows how to use the command object and delegate it to other handlers.
- Send requests in an asynchronous way: You want to send commands and don't want to wait for any response from the handler. The handler will accept the commands and perform asynchronous tasks as they will possess all the information in the command object.
- Support operations that operate on the same dataset independently: For example, say you have an editor object that represents a text editor and an editorState object that stores its state information. This could be the current position, the current text, or if you selected a text area. You want to send commands in that editor to change its state, such as undo or redo commands, and the editor will update its internal state and report back a new editor state. This way, the client would not have to know how to undo or redo an action, but they will just receive updates when the editor changes.
The pattern also makes it easy to extend the system with new commands. As long as the commands implement the same interface, you can support multiple types of actions. Let's explore the class diagram of this pattern.
UML class diagram
The UML class diagram for this pattern starts with defining the interfaces for the command and receiver operations. The commands represent the different actions that the receiver will accept. The handler will accept commands and delegate them to the receiver.
We depict the following abstractions:
Figure 5.4 – Command and Receiver objects
We define the Receiver object that exposes some methods. Instead of calling the Receiver object directly, you create commands for each of its methods. Then, you will need to define the handler that will delegate those commands on behalf of the client:
Figure 5.5 – The Command pattern
The client uses CommandHandler and calls the handle method providing a command object. This way, the Client and Receiver objects are decoupled from each other. We'll show how to implement this pattern next.
Classic implementation
Based on the previous class diagram, you can define the following classes first:
Command.ts
interface Command {
execute();
}
interface Receiver {
methodA();
methodB();
}
class ConcreteCommandA implements Command {
constructor(private receiver: Receiver) {}
execute() {
this.receiver.methodA();
}
}
class ConcreteCommandB implements Command {
constructor(private receiver: Receiver) {}
execute() {
this.receiver.methodB();
}
}
You define the Command and Receiver interfaces and some concrete implementations. Each command calls a specific method of the Receiver object. Then, you want to define the handler object that will accept commands from the client:
Command.ts
interface CommandHandler {
handle(command: Command);
}
class ConcreteCommandHandler implements CommandHandler {
private commands: Command[] = [];
handle(command: Command) {
command.execute();
this.commands.push(command);
}
}
class ConcreteReceiver implements Receiver {
methodA() {
console.log("Called method A");
}
methodB() {
console.log("Called method B");
}
}
The main elements here are the ConcreteCommandHandler class, which accepts command objects, and the ConcreteReceiver class, which is the main object that performs the actions. On the client side, they will have to provide the command objects to the handler and it will take care of the rest:
const handler = new ConcreteCommandHandler();
const receiver = new ConcreteReceiver();
handler.handle(new ConcreteCommandA(receiver)); /* logs Called method A*/
handler.handle(new ConcreteCommandB(receiver)); /* logs Called method B*/
As you can see, there are quite a few elements involved here and you will need to spend some time understanding how each element works and what its responsibilities are. The main benefit of this pattern is that it simplifies operations involving state updates. You add or remove commands to do or undo actions and so on. Let's see how to test this pattern next.
Testing
To verify that this pattern works as expected, you will have to write some test cases for each of the command objects. You will need to verify that they call the right receiver method first. Subsequently, you want to test that the CommandHandler class calls the command method as well. This chain of events should be predictable. The CommandHandler class calls the execute command method and then the right receiver method is called at the end. I'll leave these tests as an exercise for you.
Criticism of this pattern
The main criticism of this pattern is that it abstracts the code even further and makes it a bit more complicated or spread out. What this means is that because we introduce another layer of abstraction between action creators and handlers, you will have more indirection between them. Quite often, this can also be frustrating when trying to navigate around the code base as you would have to figure out the whole flow of execution and how things work before you change anything.
Real-world use case
One real-world use case of this pattern is with the Redux library, which is a state management tool for React. It is explained in more detail on their documentation site: https://redux.js.org/tutorials/essentials/part-1-overview-concepts.
In Redux, you use actions to encapsulate events that occur in the app based on user activities or triggers. Here is an example action:
const addTodoAction: Action = {
type: 'todos/addTodo',
payload: 'Buy groceries'
}
This represents the command object and it entails all the information for the handler to perform updates. On the other side, the handler in Redux is called Reducer and it's a function that receives the current state and an action and reduces or produces a new state based on that action payload:
(state: TodoState, action: Action) => TodoState
The return type of this function is a new TodoState object after it has processed the action.
As you can see, there are similar concepts involved here and it's a great way to see that pattern used in practice.
As you've understood the basic principles of this pattern in practice, you will now learn about the next one, which is the Iterator pattern.
The Iterator pattern
Iterator is an entity that knows how to traverse a list of elements in a collection in an abstracted way. You can think of this pattern as an abstraction over for loops. The main idea is that you want to iterate over a data structure without knowing its inner details or how to access its elements in a particular order. You may want to traverse the elements in a direct or reversed order by simply requesting the right Iterator object.
An analogy of this pattern is when you have a saved list of favorite shows on your hard drive. Each of these videos is saved in a different folder, but you can iterate over them one by one from your UI view without knowing the details of their location in the disk.
We explain in detail when to use this pattern next.
When to use the Iterator pattern?
You want to consider using an Iterator for the following use cases:
- Traversing a complex data structure: When you have a data structure that is not traversable via a for loop and you cannot get an internal reference to the elements but you still need to retrieve the elements in a loop fashion, then you can use an Iterator interface to retrieve the desired elements.
- Using different traversal methods: When you have a data structure or a data model that you want to iterate in multiple ways and orderings such as forward, backward, or in pairs, then instead of creating manual loops over each case, you expose an Iterator interface that can be used to traverse the elements in the right order.
In these cases, you can use an Iterator object that will encapsulate the traversal operation of the underlying data structure or an aggregate object. The main benefit for the clients that will use this pattern is that they will be able to use for loops without knowing how the objects are structured behind the scenes. We will now show you what the class diagram of this pattern looks like.
UML class diagram
When we want to describe the Iterator with UML, we start with the Iterator interface, which exposes at a minimum two methods: next() and hasNext(). Then, we want to provide a concrete implementation of this interface that implements the iteration process, as shown here:
Figure 5.6 – Iterator interface
ListNode in the diagram is the underlying data structure that you want to traverse. Once you've defined these, you want to define the aggregate object that the client will use to retrieve the Iterator for this collection:
Figure 5.7 – The Iterator pattern
LinkedListAggregate is the object that the client will use to access the collection iterator. This object would also be a good candidate for a Proxy or Factory Method pattern that we learned about in the previous chapter. You will learn how to code this pattern next.
Classic implementation
You can start implementing the Iterator pattern based on the class diagram that you saw in the previous section. First, you need to define and implement the ListIterator models:
Iterator.ts
export interface Iterator<T> {
next(): T | null;
hasNext(): boolean;
}
class ListNode<T> {
constructor(public next: ListNode<T> | null,
public data: T) {}
}
class ListIterator<T> implements Iterator<T> {
constructor(private root: ListNode<T> | null) {}
next(): T | null {
if (this.hasNext()) {
const data = this.root!.data;
this.root = this.root!.next;
return data;
}
return null;
}
hasNext(): boolean {
return this.next !== null;
}
}
We show an example implementation of iterating over a linked list in the ListIterator class. It accepts a reference to the linked list root node and implements two methods of the Iterator interface. Next, you want to implement the aggregate object and see how the client will use it:
class ListAggregate<T> {
constructor(private rootList: ListNode<T>) {}
getListIterator(): ListIterator<T> {
return new ListIterator(this.rootList);
}
}
const list = new ListNode(new ListNode(new ListNode(null, 10), 5), 15);
const aggregate = new ListAggregate(list);
const iterator = aggregate.getListIterator();
while (iterator.hasNext()) {
console.log(iterator.next()); // prints 15, 5, 10
}
ListAggregate will expose all operations of the list and can give you an Iterator that the client can invoke and traverse. The client will not know how the list is implemented but it will use the iterator API.
Testing
When you test this pattern, you want to verify that the Iterator implementation is sound. What this means is that when calling next() and hasNext() over the collection, the methods will retrieve the next item in the collection and return true or false if the next item exists, respectively. Then, in ListAggregate, you want to check whether the call to the getListIterator() method returns the correct ListIterator instance.
Criticism of this pattern
Looking at the implementation code of this pattern, you might think it has too many abstractions over a simple collection. This is indeed valid if you are working on simple lists. Then, there is no need to create all these elaborate structures.
If you don't want to create specialized iterator objects, then, using their API, you can just define a method that serializes the elements in a list. Then, you can simply iterate over in a for loop.
This way, you can prevent defining those extra abstractions in the first place.
Real-world use case
You can leverage this pattern in practice using the ES6 iterators. These are special properties that you attach to classes or objects and can denote those objects as Iterable as part of a for loop. Take the following example:
class OnlyA implements Iterable<string> {
constructor(private limit: number = 3) {
[Symbol.iterator]() {
let limit = this.limit;
return {
next(): IteratorResult<string> {
return {
done: limit-- === 0,
value: "A",
};
},
};
}
}
const a = new OnlyA();
for (let i of a) {
console.log(i);
}
Having a class implement the Iterable interface means that it needs to have the following signature:
interface Iterable<T> {
[Symbol.iterator](): Iterator<T>;
}
Then, the Iterator interface is defined as follows:
interface Iterator<T, TReturn = any, TNext = undefined> {
next(...args: [] | [TNext]):
IteratorResult<T, TReturn>;
return?(value?: TReturn): IteratorResult<T, TReturn>;
throw?(e?: any): IteratorResult<T, TReturn>;
}
This means that you will only have to provide a method named [Symbol.iterator]() that returns an object with the following type:
interface IteratorResult<T> {
done: boolean;
value: T;
}
Once you have implemented these, you can use the object in a for loop like a regular list, as we showed in the example. Implementing iterators like this can greatly simplify their usability as ES6 iterators are a native feature similar to Promises or Proxies.
Next, you will learn how to master the Mediator pattern.
The Mediator pattern
Mediator represents an object that acts as a delegator between multiple services, and its main job is to simplify the communication between them. This means it tries to encapsulate their complexities behind a simple interface so that you can change their implementation details without changing the client that uses the Mediator.
You can think of this pattern as an object that sits between one service and a complex subsystem of objects. The client will purely use the mediator service to interact with the other end so that it would not know their API or interfaces. This way, the Mediator works as a sole point of reference between them.
An analogy of this pattern is if you have to interact with a government agency but are located in a different region. To do that, you will have to hire a solicitor to get a power of attorney to perform the actions on your behalf instead of going directly to the agency.
You will learn the main reasons why you should use this pattern next.
When to use the Meditator pattern?
You might want to start using a Mediator object for some of your classes when you want to do the following:
- Reduce coupling between some of the classes and maintain only a single point of communication: You use the mediator to decouple the communication between one object and another set of objects so that you can change the latter without affecting the original. You will do that by restricting direct communication between those objects. Instead of object A having a reference to object B, it calls the mediator object to coordinate any updates to relevant objects. This way, the coupling of both objects A and B is reduced.
- Reduce complexity between two systems when they try to interact with each other: You have a set of objects that have direct communication between them, for example, when having an object A that sends a message to object B by direct method call. However, it becomes more and more complex to modify some parts without affecting the other.
Mediator shares similar traits with the Façade pattern, because it abstracts the complexity of a complex system. However, with Façade, the client would still access the subsystems through their relevant services. With the Mediator, however, this does not happen as you explicitly prohibit direct communication between objects. Thus, you make it clear that you have only one point of communication and that is through the mediator object. Let's see what the class diagram looks like for this pattern.
UML class diagram
The diagram for this pattern is shown in Figure 5.7. There are some important concepts you need to understand here. First is the Mediator interface, which consists of a series of methods that bridge some functionality between the other objects, as shown here:
Figure 5.8 – The Mediator pattern
When you define the interface for Mediator, you will need to create one concrete implementation that will aggregate all the objects that you want to depend on. Those are the objects that the client will use and, through Mediator, will communicate with each other.
For example, you don't want to directly call the BatchWorker class from the SingleTaskWorker class or vice versa. Instead, you use Mediator, which is set by the common Workhorse abstract class that both SingleTaskWorker and BatchWorker inherit from. The mediator object will be responsible for triggering different methods or events to either SingleTaskWorker or BatchWorker.
We'll explain what we mean by seeing an example implementation next.
Classic implementation
To start with, you want to define the basic interface for the Mediator and its concrete implementation. This will accept the object that it will mediate in terms of accepting events and triggering further communication paths, as shown in the following code snippet:
Mediator.ts
interface WorkerMediator {
triggerEvent(sender: object, message: string): void;
}
class WorkerCenter implements WorkerMediator {
constructor(
protected workerA: BatchWorker,
protected workerB: SingleTaskWorker
) {
this.workerA.setMediator(this);
this.workerB.setMediator(this);
}
public triggerEvent(sender: object, message: string):
void {
if (message.startsWith("single_job_completed")) {
this.workerA.finalize();
}
if (message.startsWith("batch_job_completed")) {
this.workerB.performWork();
}
}
}
In the preceding code, we highlighted the sections where the Mediator interface accepts two objects that delegate its communications. Those two objects might be related as subclasses of the same parent or completely different ones. triggerEvent is the main function in the meditator that triggers the communication between the connected object. It accepts messages from the aggregated objects and delegates them according to some business rules. This is the code for the base Worker class:
abstract class Workhorse {
protected mediator: WorkerMediator | undefined;
constructor(mediator?: WorkerMediator) {
this.mediator = mediator;
}
setMediator(mediator: WorkerMediator): void {
this.mediator = mediator;
}
}
This abstract class just assigns a WorkerMediator instance as a reference. This is used in the concrete implementation of the worker classes, which are defined next:
class BatchWorker extends Workhorse {
public performWork(): void {
console.log("Performing work in BatchWorker");
if (this.mediator) {
this.mediator.triggerEvent(this,
"batch_job_completed");
}
}
public finalize(): void {
console.log("Performing final work in BatchWorker");
if (this.mediator) {
this.mediator.triggerEvent(this,
"final_job_completed");
}
}
}
class SingleTaskWorker extends Workhorse {
public performWork(): void {
console.log("Performing work in SingleTaskWorker");
if (this.mediator) {
this.mediator.triggerEvent(this,
"single_job_completed");
}
}
}
We highlighted the sections where the mediator instance is used in the method calls. This is to ensure that whenever a worker performs a task, it notifies the mediator to perform the communication logic. In this example, if the mediator receives the event messages from SingleTaskWorker, it will call the finalize() method of BatchWorker.
This way, you can add or remove events that happen on some operations and the mediator will handle the follow-up. This is how the client will use this pattern:
const workerA = new BatchWorker();
const workerB = new SingleTaskWorker();
const mediator = new WorkerCenter(workerA, workerB);
workerA.performWork();
The mediator is passed along as a reference to each worker. The client will use the objects as usual but now the bundled mediator will accept any notifications and trigger relevant methods to other objects.
Testing
When testing this pattern, you want to verify that the mediator responds to the events from the objects it listens to and delegates their events in a specific order. For example, when it accepts a message from a particular sender, then it should trigger a message to the relevant objects based on that business logic we defined. In our example, if you get a message from SingleTaskWorker, then you should expect another message to the finalize() method of BatchWorker.
On the other hand, you want to check whether the concrete components trigger a message to the mediator during their method calls. This is to ensure that the mediator receives events as well.
Criticisms of this pattern
If you have noticed already, using the Mediator class creates some additional problems if you are not careful. For example, you might easily introduce stack overflows; if one service calls the other through the Mediator, then you risk calling the same function again, which triggers the mediator with the same event. This would create an infinite loop. In our example implementation, if you replaced the first call in the mediator with the following code, it would create a stack overflow:
if (message.startsWith("single_job_completed")) {
this.workerB.performWork(); // stack overflow error
}
You will need to be extra careful when designing the communication flows between an object and the mediator so that you don't fall into that trap.
Additionally, you can create some complex interactions that would be tricky to test. The mediator will become a single point of interaction and might become extremely complex to debug. When considering using this pattern, you need to have a clear set of interactions you want to decouple to avoid that unnecessary complexity.
Real-world use cases
There are many good use cases where you can apply the Mediator pattern in practice. Here are some suggested options:
- Chatroom application: You are designing a chatroom application and you create entities for the chatroom, chat users, and inbox. You want to implement a feature to allow two users to communicate with each other via direct messages. You don't want to allow one user to directly receive a reference of another user to send a message. Preferably, you'd use a mediator to trigger message events so that whenever a message is posted, it will forward it to the right recipient.
- UI elements interacting with each other: You have some UI elements such as an icon with a counter, and in some parts of the application you have a button that, when you click on it, should update that counter after it has performed an operation. You may use this pattern to trigger an event when the button completes the operation so that the mediator will forward a new counter update for that icon.
As always, you should always think twice before applying this pattern as you will have to make sure it does not become too big or full of surprises when used in production. Hopefully, if you can apply reason, you will gain lots of benefits from this pattern.
Next, we will understand more about the Observer pattern.
The Observer pattern
Observer is a behavioral design pattern that establishes a subscription model of communication. In simple words, you use a publisher object that posts messages to a list of active subscribers either in regard to some events that occur or when a specific rule is activated. Those rules could be some points of interest. For example, say you want to send notifications after a user has registered or some part of your application needs to get an update from a different part of the application.
This way, you establish a one-to-many communication model between the publisher and the subscriber list. The publisher would not know what the subscriber list looks like. It only allows a reference to an interface that can push messages into it.
On the other side, the subscriber will receive events from the publisher that it subscribes to and has the choice of acting on or disregarding them. If the publisher somehow gets destroyed, subsequently it will remove any references to the subscriber list so the subscriber will also be lost if it's not used somewhere.
Let's explain when to use this pattern next.
When to use the Observer pattern?
The main use cases of this pattern are as follows:
- Create a one-to-many communication between objects: This is when you have an object that publishes events to multiple objects in a decoupled way. The publisher does not know the details of the subscriber list and it can change its implementation details irrespectively. For example, say you have a Counter store object that counts clicks of a web page. You also have multiple widgets that show the count of the web page. When the Counter store gets updated, you want the widgets to reflect the current count as well.
- Trigger events to different parts of an application without coupling dependencies: The subscribers join the publisher object mainly because it needs to receive updates for specific cases. Then, it will perform its internal business logic or update its own state. This way, you can update different parts of the application without even passing references of objects as parameters.
In this pattern, the publisher is also named Subject, which controls the flow of events. When it is time to notify the subscribers, it will call a special method called notify and the pattern will iterate over all the subscriber lists and pass on any updates.
Using the Observer pattern, you can chain multiple handlers in the notify method and that makes it very flexible. This is where you can combine the effects of the Chain of Responsibility pattern to perform filtering and transformation before the subscribers receive the events. For example, say you publish some numbers but on the subscriber side, you are only interested in certain numbers, for example, only positive numbers. You can add a Chain of Responsibility handler that filters the negative numbers before sending them to subscribers. You will see more detailed examples of this idea in Chapter 7, Reactive Programming with TypeScript.
UML class diagram
The UML diagram for this pattern follows the ideas that we mentioned previously. We show all the pieces together in the diagram here:
Figure 5.9 – The Observer pattern
Subject represents the object that holds the state of the application and notifies the subscribers of any updates of this state. Subscriber represents the Observer object that listens to events from Subject. The shared state property is retrieved by the Subscriber object once it is notified by Subject.
The Subject object also has the ability to add or remove subscribers on the fly. This is to ensure the dynamic nature of the list and to ensure accurate message passing. We show how to implement this pattern next.
Classic implementation
We implement the Observer pattern using the UML class diagram as a reference. We can define the Subscriber interface and a concrete implementation of the Subject class that manages some sort of internal state:
Observer.ts
interface Subscriber {
notify(): void;
}
export abstract class Subject {
private subscribers: Subscriber[] = [];
public addSubscriber(s: Subscriber): void {
this.subscribers.push(s);
}
public removeSubscriber(s: Subscriber): void {
var n: number = this.subscribers.indexOf(s);
this.subscribers.splice(n, 1);
}
public notify(): void {
console.log("notifying all the subscribers one
by one");
for (let s of this.subscribers) {
s.notify();
}
}
}
Subscriber accepts only one method, called notify(). The responsibility of calling this method lies with Subject. The notify() method iterates over the subscribers list and calls the interface method on each of them. Let's see what will happen during that call:
Observer.ts
export class ConcreteSubject extends Subject {
private state: any;
getState(): any {
return this.state;
}
setState(state: any) {
this.state = state;
}
}
export class ConcreteSubscriber implements Subscriber {
private state: any;
constructor(private subject: ConcreteSubject) {}
public notify(): void {
this.state = this.subject.getState();
console.log("ConcreteSubscriber: Received notify method from subject state", this.state);
}
getSubject(): ConcreteSubject {
return this.subject;
}
setSubject(subject: ConcreteSubject) {
this.subject = subject;
}
}
ConcreteSubscriber receives a message from the Subject class through notify() and retrieves the current subject state via the this.subject.getState() call. Alternatively, you can also perform the same operation by passing the state as a parameter in notify:
for (let s of this.subscribers) {
s.notify("message");
}
This is a more direct approach of passing the right message or state to subscribers. The following is how the clients will use this pattern:
const subject = new ConcreteSubject();
const subA = new ConcreteSubscriber(subject);
subject.addSubscriber(subA);
const subB = new ConcreteSubscriber(subject);
subject.addSubscriber(subB);
subject.setState(19);
subject.notify();
// notifying all the subscriber list
//ConcreteSubscriber: Received notify method from subject state 19
//ConcreteSubscriber: Received notify method from subject state 19
The Subject class adds all subscriber lists at runtime. Then it updates its state property and calls notify(). This will trigger all the associated subscribers who will receive the new state and perform their own updates. This way, the communication between the subject and the subscriber list is decoupled. We'll describe some ideas of how to test this pattern next.
Testing
When testing this pattern, you want to establish the following test criteria. First, you need to have a solid Subject implementation that does not hold references or introduce memory leaks when destroyed. It needs to clean up its resources properly. The methods for unsubscribe should also be consistent and remove the associated subscribers from the list for any subsequent messages. Then, for each observer, you will need to write test cases that perform correct business logic when they receive a message from Subject.
All of those tests can be performed simply by using a test subject for the subscribers and a test subscriber for the Subject objects to verify that they trigger and receive messages.
Criticisms of this pattern
While this pattern is quite well established, there are some important caveats you need to know before you consider it. The most important consideration is that this pattern suffers from memory leaks if not used correctly.
The list of subscribers is notified in linear order, so if you have a really big list of them, then you will have some pauses at regular intervals because the runtime will iterate in linear time and it may block the current context.
Real-world use case
This pattern is used quite frequently in production systems because of its flexibility. You will examine the real-world use cases of this pattern in Chapter 7, Reactive Programming with TypeScript. For reference, we will explain the usage of Observables, which is a construct that builds upon the principles of reactive programming, functional programming, and the Observer pattern. You will learn how to use RxJS, which is a reactive programming library to create, operate, and combine Observables at scale.
Next, you will explore the Memento pattern.
The Memento pattern
Memento is a pattern that deals with saving and restoring an object's state across parts of the application without exposing any implementation details. You can think of it as a state management pattern that offers a simple way of storing data in a repository and then when needed, restores the previous data on demand.
There are three main components of this pattern. You have an object called the Caretaker to maintain a list of Memento objects that offer a simple interface to store and retrieve a state. The last component is the Originator object, which is the object that uses the state to perform its business logic. The Originator coordinates with the Memento object whenever it wants to save or restore its state. The two entities (Caretaker and Originator) do not depend on each other when managing this transition of a state as you abstract all the logic inside the Memento.
Let's explain in more detail when to use this pattern.
When to use the Memento pattern?
The key reasons to use this pattern are as follows:
- Supporting save and undo save functionality over an object's internal state: Say you want to make copies of the state of an object including private properties and have them stored in a reproducible way. Then, you want to be able to restore this copy on demand when needed in a way that does not break consistency. For example, when storing the state of an object and then restoring it immediately, you should get back the original object with no changes.
- Don't want to expose any implementation details or the state object to the client: You don't want the save or restore operations to expose implementation details to the client. The client will only have to use a service to select a memento object from a list and restore the previous state in the Originator object.
Use the Memento pattern when you want to perform save and restore operations on an object's state on demand. Because this pattern is relatively simple to understand and has a straightforward use case, it is not difficult to incorporate it.
We will see how we can depict this pattern using UML classes next.
UML class diagram
The following diagram shows the main components of the Memento pattern:
Figure 5.10 – The Memento pattern
The AppState interface represents the state object that you want to save or restore. The Originator class holds this state to perform work and updates it when required. Then, it will call the save() method, which will return a Memento object. Because this object is of no use to the Originator, you need a CareTaker class that will aggregate all those memento objects. Think of CareTaker as a storage object. When the user wants to restore a previous memento, they will use the restoreLastMemento() method, which will update the CareTaker state directly. Let's see how to implement this pattern in practice next.
Classic implementation
Following the previous diagram, you can implement the components of this pattern as follows:
Memento.ts
interface AppState {
data: any;
}
abstract class Memento {
constructor(protected state: AppState) {}
getState(): AppState {
return this.state;
}
}
class ConcreteMemento extends Memento {
getState(): AppState {
return super.getState();
}
}
Memento is just an abstract class that retrieves the current AppState object. You can then extend this abstract class to provide one or more specific implementations on how to serialize this AppState object. Then, you will need to define the rest of the components as follows:
Memento.ts
class Originator {
constructor(private state: AppState) {}
save(): Memento {
return new ConcreteMemento(this.state);
}
restore(memento: Memento): void {
this.state = memento.getState();
}
}
export class CareTaker {
constructor(
private originator: Originator,
private mementos: Memento[] = []
) {}
restoreLastMemento() {
if (this.mementos.length === 0) {
return;
}
const memento = this.mementos.pop()!;
this.originator.restore(memento);
}
saveMemento(memento: Memento) {
this.mementos.push(this.originator.save());
}
}
The last two classes represent the Originator and Caretaker objects. This just creates a new memento object, passing its own state and that can restore a previous state from a different memento. Caretaker aggregates the list of mementos and offers a simple API to restore or save a memento. Here is how the client will use this pattern:
const state: AppState = {
data: "paste data",
};
const originator = new Originator(state);
const caretaker = new CareTaker(originator);
console.log("Originator data:", originator.save().getState().data); // Originator data: paste data
state.data = "many more data";
caretaker.saveMemento();
caretaker.restoreLastMemento();
console.log("Restored data:", originator.save().getState().data); // Restored data: many more data
The originator object manipulates its state internally. The client just uses the caretaker object to save or restore a state. You can inspect the state directly from the originator object before and after those operations. As far as the originator object is concerned, it does not know or control how its state object is being delivered. This makes this pattern very useful, for example, in web applications when you want to monitor and record how the state of the application has changed before or after some operations.
Testing
When testing this pattern, you want to test first that the Memento saved and restored a state object correctly and consistently. Then you want to add test cases for the Originator when it calls the save/restore methods to test whether it returns the correct Memento state. Lastly, you want to make sure the Caretaker object properly aggregates the list of Memento objects and can retrieve the list of them when asked by the client.
Criticisms of this pattern
The obvious drawbacks of this pattern are that it's quite complex and abstract. There are numerous alternative ways to manage state in applications, especially in web environments, and most of the time a simpler approach is better.
This pattern may also introduce memory leaks or spikes in memory usage, if you don't control the number of mementos stored in the system. You have to manually control the list of subscribers and make sure to unsubscribe before the object is destroyed.
However, for some special cases, this pattern is a good candidate. We will see a real-world use case of the Memento pattern next.
Real-world use case
One good real-world use case of this pattern is when you have an editor and you perform edits, and for each distinct edit, you save a revision. Each revision is basically a Memento object and the Editor class represents the Originator object. The Caretaker may represent the page that shows the revision list where the user may pick one revision and restore the document to that state. We show some example code for this case as follows:
interface EditorState {}
class Editor {
constructor(private state: EditorState) {}
public save(): Revision {
return new Revision(this.state);
}
public restore(revision: Revision): void {
this.state = revision.getState();
}
}
class Revision {
constructor(private state: EditorState) {}
}
class RevisionList {
private revisions: Revision[] = [];
constructor(private editor: Editor) {}
}
As you can see, the code is identical to the classic implementation of the Memento. You can have a list of maintained revisions for each document where you can give the option to the client to restore to a previous revision. This makes this pattern really useful in practice.
Next, we will delve into the details of the State pattern.
The State pattern
The State pattern deals with state management concerning a particular object and, more specifically, how to make an object behave differently based on its inner state. You have an object similar to the Originator object that you learned about in the Memento pattern. Then, at runtime, you change its internal state and the object will behave differently when used by the client.
You can think of this pattern as having a state machine that changes the behavior of an object when its internal state changes. Because you will be placing logic statements based on the object's state parameter, it is useful if you want to implement inheritance without actually defining subclasses.
We'll explain in detail when to use this pattern.
When to use the State pattern?
You can use the State pattern in the following cases:
- You have an object that responds differently depending on its internal state: Say you have an object that operates internally based on some data parameters of its own. For example, it may be certain flags, types, or values that make the object perform differently. You want to be able to provide different values so that the object can change its behavior.
- Changing the object's behavior on the fly without changing its class: You want to have one object accept a state that will define its behavior at runtime but without subclassing a new object. Instead, you change its behavior by accepting a state object.
- Defining many different states for an object: You want to define many different state objects that encapsulate a specific behavior at runtime just by interchanging them.
The main benefit of this pattern is that you can encapsulate all the behaviors in one place and respond based on the existing state that the object holds. If you have many independent state variants, then you will avoid much code duplication when using this pattern.
The logic of switching from one state to another is arbitrary, and it depends on the business case as well. You may perform this operation internally but most of the time, it will be done externally. The client or another pattern will know the current state and what method to call to transition to another state. We show the UML class diagram of this pattern next.
UML class diagram
We showcase the whole class diagram of this pattern here:
Figure 5.11 – The State pattern
Originator owns a single state object, which can have many forms. You can use either subclassing or a Factory Method pattern to have different variations of the State interface. The call to the changeState() method assigns a different state object to the Originator. Then, the Originator will behave according to its current state.
Classic implementation
The implementation of this pattern follows the class diagram details. First, you need to define the State object interface and its parameters:
State.ts
interface State {
onEnterState(): void;
reportState(): void;
data: any;
}
The onEnterState and reportState methods are optional and are used for introspection of the events. For example, you may want to track when the state changes and print the current state information. The data parameter is an example property that holds specific values. Then, you will need to define at least two concrete implementations of this interface:
State.ts
export class PassiveState implements State {
data: any;
constructor() {
this.data = "Passive data";
}
reportState(): void {
console.log("Originator is in passive mode currently");
}
onEnterState(): void {
console.log("Originator changed into passing mode");
}
}
export class ActiveState implements State {
data: any;
constructor() {
this.data = "Active data";
}
reportState(): void {
console.log("Originator is in active mode currently");
}
onEnterState(): void {
console.log("Originator changed into active mode");
}
}
The state objects are like data classes as they are mostly only there for holding data values. The logic of using these state objects is performed in the Originator object. Here is what it looks like:
State.ts
export class Originator {
private state: State;
constructor() {
this.state = new PassiveState();
}
changeState(state: State) {
this.state = state;
this.state.onEnterState();
}
reportState(): void {
this.state.reportState();
}
}
This object is the current holder of the state and knows how to use it. The client can call the changeState method to change to a different state. Then, the behavior of this object will change based on the values of the state. This is how the client will use this pattern:
State.ts
const originator = new Originator();
originator.reportState(); // Originator is in passive mode currently
originator.changeState(new ActiveState()); // Originator changed into active mode
originator.reportState(); // Originator is in active mode currently
The client will use originator as normal and when they want to change its behavior, they will call the changeState method, passing a new state object. Then, when calling the reportState method, the Originator object should behave depending on their current state object. For example, you may have certain if statements that return different results based on a value of the state. We will explore some testing strategies next.
Testing
When you write tests for this pattern, you want to verify a few cases. Each state type you define should capture the right state parameters and you should verify that the data they hold is correct. Then, you want to verify that the state transition logic is correct when you call the changeState() method. For example, when changing state, the object should behave accordingly based on its current state. You can find example test cases in the project's source code folder at the following link:
https://github.com/PacktPublishing/TypeScript-4-Design-Patterns-and-Best-Practices/blob/main/chapters/chapter-5_Behavioral_Design_Patterns/State.test.ts
Criticisms of this pattern
The main criticism of this pattern is that it makes it difficult to know how to define the states in a way that they provide real value without much repetition. If you allow only a few variations that you need to check, then it may not be worth the effort of using this pattern. In that case, you can merely use the Bridge pattern to define multiple implementations of the same abstraction.
It's also very tricky to cover all the internal edge cases when you work with different state objects. If you don't cover all the cases, then you might have to cover it with error states, which you also need to define as well. This whole process might not be worthwhile if you can use some if statements to do the same thing simpler. Let's explore a real-world use case of this pattern.
Real-world use case
Using state machines in web applications is a very common pattern. You have a button or a dialog that behaves differently based on some status parameters. You can enhance this functionality to use the State pattern. Here is a rough example implementation:
interface ButtonState {
status: "loading" | "disabled" | "active";
text: string;
icon: string;
}
This ButtonState interface represents the state of a button. It contains status, text, and icon properties. Let's create some concrete implementation of this state:
class ActiveButtonState implements ButtonState {
status: ButtonState["status"] = "active";
text = "Click me";
icon = "click_me_icon";
constructor(private originator: Button) {}
}
We instantiate a class that implement this state. Next, you want to define the button that uses that state:
export class Button {
private state: ButtonState;
constructor() {
this.state = new ActiveButtonState(this);
}
changeState(state: ButtonState) {
this.state = state;
}
render(): string {
const { text, icon, status } = this.state;
let disabled = false;
if (status === "loading") {
disabled = true;
}
return '<button disabled=${disabled}><img
src=${icon}/>${text}</button>';
}
}
The render method inside the Button class will change its representation depending on its current state object. For example, if it's currently in the loading state, then it will show a loading button. Otherwise, it will show its active state. You can also define different state objects that will configure a different state for the button that will render a different HTML.
Next, we will look at the concepts of the Template method pattern.
The Template method pattern
The Template method pattern is used to define a basic template of an algorithm and have subclasses override specific steps at runtime. This means that you have a series of steps in an algorithm but you want to consider having placeholder calls that delegate the logic to subclasses. Depending on the result, the algorithm behaves differently, which means that this pattern leverages inheritance to provide specialization.
You mainly want to employ this pattern because it can get very repetitive to create similar methods that perform the same operation, such as checking a specific state variable, but differ in some aspects. Let's explain in detail when to use this pattern.
When to use the Template method pattern?
You want to use this pattern when faced with the following problems:
- You need to keep parts of an algorithm or a process the same but have some methods implement the specialized behavior: The basic steps of the algorithm are the same but in specific cases, you want to provide variations. For example, when using sorting algorithms, you want to sort in ascending or descending order. The sorting operation will call a method that needs to be defined in the subclass about the sort order of the items. Then, based on the implementation, the template method will arrange the items in the right order.
- You want to avoid code duplication when a process workflow is the same in most of the parts: You have identified some parts of the algorithm that do not change, but some can be delegated to inherited or callback methods. You want to let the subclasses implement this logic with the main body of the algorithm unchanged.
You can think of this pattern as having an algorithm in a method, and in certain steps, it calls another method that is implemented in the subclasses to perform some specific logic. This method could either return a result or just return nothing. The subclasses can choose to implement these life cycle methods to return some specific results or ignore them if they are optional. This way, you can write code that has customized behavior but still does not introduce extra code duplication. Let's see what this looks like as a UML class diagram.
UML class diagram
The class diagram of the Template method is simple in nature. You have a base abstract class that implements some steps of an algorithm or a process, and then you have some abstract methods that you let the subclasses override. This is what it looks like:
Figure 5.12 – The Template method pattern
The base class is ShippingItemsTemplate, which defines some common steps to ship items through a carrier. The prepareItems method is common and does not change. However, subclasses need to implement the performShipment method, which sends the items through the carrier.
The two implementations for air and land shipments inherit from the base class and implement the correct method. There is also an optional method called onItemsShipped, which is a life cycle method that is called after the call to the performShipment method. Classes may implement this to perform optional tasks but, by default, this method is not implemented.
Let's explore in detail the implementation part of this pattern.
Classic implementation
The classic implementation of this pattern follows the class diagram that we explained in the previous section. First, you need to define the Template method class that hosts the basic steps for the algorithm. In our example, we define the ShippingItemsTemplate class as follows:
TemplateMethod.ts
abstract class ShippingItemsTemplate {
shipItems(items: string[]): void {
this.prepareItems(items);
this.performShipment(items);
this.onItemsShipped(items);
}
protected prepareItems(items: string[]): void {
console.log("Preparing items to be shipped to
destination");
}
protected abstract performShipment(items: string[]):
void;
protected onItemsShipped(items: string[]): void {}
}
This abstract class defines the steps of the algorithm in the shipItems method. Each step of the algorithm calls respective methods that can be either required or optional. Next, each subclass needs to implement the required methods of this algorithm. We define those next:
TemplateMethod.ts
class AirShipment extends ShippingItemsTemplate {
protected performShipment(): void {
console.log("Shipping items by Air");
}
protected onItemsShipped(items: string[]): void {
console.log("Items shipped by Air. Expect quick
arrival.");
}
}
class LandShipment extends ShippingItemsTemplate {
protected performShipment(items: string[]): void {
console.log("Shipping items by land");
}
protected onItemsShipped(items: string[]): void {
console.log("Items shipped by land. Expect
slow arrival.");
}
}
Each class implements the performShipment method because it's required to satisfy the abstract class extension. When the client assigns an implementation at runtime, then the right method is dispatched via polymorphism:
const airShipment: ShippingItemsTemplate = new AirShipment();
const landShipment: ShippingItemsTemplate = new LandShipment();
airShipment.shipItems(["Chips", "Motherboards"]);
landShipment.shipItems(["Chips", "Motherboards"]);
The client assigns an instance of ShippingItemsTemplate and it will dispatch the right template methods at runtime. This way, you gain flexibility by not having to reimplement the same steps each time. Next, we discuss some testing strategies.
Testing
When writing tests for this pattern, you want to verify that the subclasses deliver the expected outcomes. This is because you cannot create instances of the abstract class so you want to test the algorithm outcomes of the extensions. For example, you can write a test that checks that the algorithm steps are executed in a specific manner. Some steps are common as they are part of the template method. The other steps are part of the subclass specialization that also need to be verified as well.
Criticism of this pattern
This pattern, although quite frequently used in several established libraries such as React, suffers from a significant drawback. If you have some template steps that you want to deprecate and you have already shipped your code to clients, then it's quite tricky to remove them without breaching their code. This makes the pattern limited if you want to retain that flexibility in such cases. As a general rule, try defining fewer required or optional steps for customization so that it's easy to change the base template without having to deprecate methods in the future. We explore a popular use case of this pattern next.
Real-world use case
React popularized the idea of the Template method, more specifically, with the React.Component class. These are React components defined as a class. They have some optional life cycle hook methods that are called at various stages, such as just before or after mounting in the DOM or before or after updating. For example, here is an example component:
class WelcomeHome extends React.Component<{name: string},{}> {
componentDidMount() {
console.log("Just loaded");
}
componentWillUnmount() {
console.log("Goodbye!");
}
shouldComponentUpdate() {
return false;
}
render() {
return <h1>Hello, {this.props.name}</h1>;
}
}
Out of all those methods, the render method is the required one and each React component needs to define one that returns another React component or null. However, there are also other optional life cycle methods, componentDidMount, componentWillUnmount, and shouldComponentUpdate, that are called by React at different times. You can define these methods and adhere to the reasoning behind them if you want to further customize the behavior of the WelcomeHome component.
We'll now explore the last behavioral design pattern of this chapter, which is the Visitor.
The Visitor pattern
The last pattern we are going to explore is the Visitor pattern. This pattern deals with applying customized behavior to an existing list of components that form a hierarchy (a tree or a linked list) but without changing their structure or having them implement an interface.
In practice, this means that you make your components have a method that accepts a reference of a Visitor object and passes its own instance as a parameter to this visitor. The visitor, on the other hand, will have access to each type of visited object's public methods and they can aggregate the state of each object it visits into a different result.
We'll now explain in more detail when to use this pattern.
When to use the Visitor pattern?
The primary use cases of this pattern are explained as follows. You want to use this pattern in the following cases:
- You want to abstract some functionality for collecting the public state of a hierarchy of objects: You have a composite hierarchy of objects and you want to traverse through them, collecting some parameters or state variables. You don't want to call that object's public methods directly because sometimes they only exist for those objects and not on the base classes and it will make it difficult to check the type every time.
- You want to apply one or more new operations to a group of objects that share the same interface but have concrete subclasses: That group of objects implements an interface but their subclasses have specific methods you want to use. You create a concrete visitor for those subclasses and let it use those methods for accumulating information.
This pattern is the most complex one we've seen so far. This is because you will need to first define the compound hierarchy of objects and their implementation, then the visitor interface for that base composite type and specialized concrete implementations of the Visitor for each type of subclass you want to aggregate. Next, you need to force the composite types to implement the accept(visitor: Visitor): void; method, which will assign its instance to the passed visitor.
What you gain from this pattern is it allows you to add functions to existing classes without modifying their source. As long as the data you have is accessible using the public instance methods, you can use different Visitor implementations that perform logic on those objects without changing their internal structure.
Let's see how this pattern translates to a UML class diagram.
UML class diagram
The class diagram of this pattern is exhibited in Figure 5.13. You have the basic interface of AcceptsVisitor, which requires a single method for accepting a visitor object. Then you have the DocumentVisitor interface, which defines the methods for the actual visitor class. Then you have concrete implementations of both AcceptVisitor and DocumentVisitor plus the implementation of the Composite pattern we explored in the previous chapter:
Figure 5.13 – The Visitor pattern
The logic of this diagram goes as follows. ConcreteDocumentVisitor knows how to accept and use the special ConcreteDocumentA and ConcreteDocumentB subclasses because it accepts them as parameters. On the CompositeDocument side, you have a single accept method that iterates over the private instances of the AcceptVisitor interface and calls this method on each one of them. This will trigger polymorphic calls to the passed visitor instance parameter. Let's get into the implementation details next.
Classic implementation
We will now show and explain the implementation of this pattern using classic OOP techniques. We define the interfaces first:
Visitor.ts
export interface DocumentVisitor {
visitConcreteDocumentA(concreteDocumentA:
ConcreteDocumentA): void;
visitConcreteDocumentB(concreteDocumentB:
ConcreteDocumentB): void;
}
export interface AcceptsVisitor {
accept(visitor: DocumentVisitor): void;
}
Both interfaces define the methods for the visitor and the composite component, which accepts the visitor type. Notice that DocumentVisitor accepts a concrete type so it knows a little bit of the types it tries to aggregate.
Next, we define the concrete implementations of these interfaces:
Visitor.ts
export class ConcreteDocumentA implements AcceptsVisitor {
accept(visitor: DocumentVisitor): void {
visitor.visitConcreteDocumentA(this);
}
}
export class ConcreteDocumentB implements AcceptsVisitor {
accept(visitor: DocumentVisitor): void {
visitor.visitConcreteDocumentB(this);
}
}
export class ConcreteDocumentVisitor implements DocumentVisitor {
visitConcreteDocumentA(concreteDocumentA:
ConcreteDocumentA): void {
console.log("ConcreteDocumentVisitor visits
ConcreteDocumentA");
}
visitConcreteDocumentB(concreteDocumentB:
ConcreteDocumentB): void {
console.log("ConcreteDocumentVisitor visits
ConcreteDocumentB");
}
}
The implementation part for the AcceptsVisitor interface just delegates the relevant method from the provided visitor type. You just have to be careful to call the right method of course.
Finally, we define the composite structure that contains the object hierarchy and see how the client will use it in real life:
Visitor.ts
export class CompositeDocument implements AcceptsVisitor {
private documents: AcceptsVisitor[] = [];
public addDocument(d: AcceptsVisitor): void {
this.documents.push(d);
}
public accept(visitor: DocumentVisitor): void {
for (let document of this.documents) {
document.accept(visitor);
}
}
}
const composite = new CompositeDocument();
const visitor = new ConcreteDocumentVisitor();
composite.addDocument(new ConcreteDocumentA());
composite.addDocument(new ConcreteDocumentB());
composite.accept(visitor);
Here, CompositeDocument contains a list of documents that can accept a visitor. The call to accept will iterate over those documents and pass on the visitor object. This will end up calling the concrete visitor methods for each type of document. Let's see how to test this pattern.
Testing
There are several tests you need to perform for this pattern to ensure accuracy. First, you need to test that the composite component forwards the visitor to each component. Then, you can test whether each individual component that accepts the visitor calls the right visitor method. Lastly, you want to check that the concrete visitor methods for each passed component type perform as expected and they use the right methods. Using the testing examples from previous sections, you can easily verify those assumptions. We explain some of the most important criticisms of this pattern next.
Criticisms of this pattern
The obvious caveat that we identified is that you need to make sure to call the right visitor methods for each component. Additionally, because you use concrete parameters in the Visitor interface, it makes it more prone to change. For example, if you want to add another handler for a new component, ConcreteComponentC, you will have to update all visitors that rely on this interface.
Finally, as you may notice, you can only access the public methods and properties of each component you visit. This means that a lot of the time, you can perform some aggregation without using a visitor by simply defining a custom iterator or a reducer that collects some data from the hierarchy.
Real-world use case
The most common case for implementing this pattern is if you want to support multiple export types in applications. Imagine you have a text editor that stores text nodes of different types (annotated, bold, or underlined) and you want to support exporting to Markdown, PDF, or HTML. Traditionally you will have to traverse through the composite hierarchy and try to check each instance type of the node before calling the right method to extract the node state information.
With visitor, you will just have to extract this functionality in one place and provide concrete handlers for each type of export you want. For example, we have one for HTML and one for PDF:
class HTMLDocumentVisitor implements DocumentVisitor {
visitNodeTypeA(nodeTypeA: NodeTypeA): void;
visitNodeTypeB(nodeTypeB: NodeTypeB): void
}
class PDFDocumentVisitor implements DocumentVisitor {
visitNodeTypeA(nodeTypeA: NodeTypeA): void;
visitNodeTypeB(nodeTypeB: NodeTypeB): void
}
As long as the composite component can accept a visitor object and you don't have to change many nodes, you can define multiple visitors that implement a different export type.
Summary
This chapter demonstrated all the fundamental aspects of behavioral design patterns and how to efficiently utilize them in practice. Those patterns focus on the communication connections among objects and how they perform them without introducing unnecessary complexity in the process.
You started by practicing the basics of the Strategy pattern for developing interchangeable algorithms. Then you discovered the details of the Chain of Responsibility pattern and how to create middleware that processes a request through multiple handlers. You also explored how the Command pattern uses standalone objects that contain all the information about a particular request. Using the Iterator pattern, you learned how to access a traversable structure in a way that does not expose its internal details. Next, you explored how the Mediator pattern can simplify the direct communication between objects. After that, you understood the core principles of the Memento pattern for storing and restoring state. You also used the Observer pattern to define a publish-subscribe model for communication. Then, you used the State pattern to dynamically change an object's behavior based on its internal state. By using the Template method pattern, you defined a basic skeleton of an algorithm and let the subclasses complete the remaining steps. Lastly, using Visitor, you learned how to add new operations to a class hierarchy without changing them.
Using these patterns will help you to create flexible and extensible components that delegate their responsibilities to relevant objects. In the next chapter, we will switch gears and start learning some advanced concepts and best practices related to functional programming using TypeScript.
Q&A
- How is Mediator different compared to the Observer pattern?
Both patterns work in a similar manner; however, their goals are marginally different. The goal of the Mediator is to eliminate direct communication between system components. With a Mediator, you usually know the dependent structures and perform calls based on the events that it receives. With Observer, you are slightly more loosely coupled as the publisher does not identify the details of the subscriber list. Some subscribers might choose to ignore certain messages, and some may choose to respond to them.
- How is the Chain of Responsibility different compared to the Decorator pattern?
The Decorator pattern usually extends one object's behavior and does not try to block the flow of requests. With a Chain of Responsibility, you are allowed to break the flow under certain criteria.
- How is Visitor different compared to the Composite pattern?
The Visitor pattern works together with the Composite pattern and it can be used to execute an operation over an entire composite hierarchy. Their differences lie in the problems they try to solve as Visitor is a behavioral pattern and Composite is structural. The Visitor tries to separate an algorithm from an object structure on which it operates, but the Composite sees a group of objects treated the same way as belonging to the same type.
Further reading
multiplies 2 and 3 to give 12 (1 ms)
g
