Software Design Patterns

Chain of Responsibility

(From https://www.fluentcpp.com/2021/07/26/design-patterns-vs-design-principles-chain-of-responsibility-command-and-interpreter/)

The design pattern Chain of Responsibility consists in putting in place a sequence of objects that fallback on each other to handle a request.

That is, a client sends a request to the first object of the sequence. If it can handle it, it does. Otherwise, it passes on the request to the second object of the sequence. And so on

Command

(From https://www.fluentcpp.com/2021/07/26/design-patterns-vs-design-principles-chain-of-responsibility-command-and-interpreter/)

The design pattern Command consists in creating a class to represent the execution of an action, as opposed to having the calling code contain the code of the action.

This resulting class is supposed to be autonomous, in that any caller can invoke it, without passing it additional parameters. It is its constructor that takes all that is needed to perform the operation:

class MyCommand
{
public:
    // constructor
    void execute();
private:
    // All the stuff needed to perform the action
};

The above code is the Java-like traditional presentation of the Command design pattern, but the Command pattern can take various forms. For example, it can take the form of a lambda:

auto myAction =
  [stuffToPerformTheAction]
  ()
  { /* action */ };

One of the benefits of the Command pattern is that the actions become manipulable by themselves: they can be stored, sorted, invoked at a later time, repeatedly invoked, etc.

To me, the Command pattern allows to create a class that revolves around one single focus: executing an action. Seen this way, it is a way to create High Cohesion. And more precisely than this, it is a Pure Fabrication. Indeed, lambdas don't map to something in the domain, in general.

It can be argued that Command involves Polymorphism as well. The GoF book even suggests to add a base class above the objects that perform the action, with a virtual method execute(), in order to have various types of actions behind a unified interface.

This is certainly useful, but my understanding of the pattern is that its essence is about introducing a class to represent the action. Using this class polymorphically is a only a nice addition.

Interpreter

(From https://www.fluentcpp.com/2021/07/26/design-patterns-vs-design-principles-chain-of-responsibility-command-and-interpreter/)

The Interpreter design pattern helps achieving modular design when processing an Abstract Syntax Tree (AST) of a given language.

The AST is the structured representation of an expression in the form of a tree, stemming from the fact that expressions can be made of sub-expressions: the children of a node in the AST are the subparts of the expression represented by that node.

The GoF book takes the example of the language of regular expressions: a given regex can be represented in the form of an AST.

The Interpreter design pattern consists in defining a base class for an expression, with a method called interpret. And then defining one class derived from this base classe for each type of the sub-expression in the language. Each class implements the the method interpret() of its base class, potentially by forwarding some of the work to its children in the AST. The nodes of the AST are made of those classes.

interpret can takes a Context as a parameter. The Context can contain something to be matched up or updated with the expression represented by the AST.

In the example of the AST representing a regular expression, the context contains the string to match it up with. For an AST representing C++ code, the context can contain the object code to output based on the traversal of the AST.

The essence of the Interpreter design pattern lies, in my opinion, in Polymorphism. Indeed, the base class allows to build up a tree in a generic way, and the concrete classes perform the job depending on each sub-expression.

Iterator

Thanks to the STL, we C++ developers are familiar with iterators. Is the GoF design pattern Iterator similar to STL iterators?

class Iterator
{
    First()
    Next()
    IsDone()
    CurrentItem()
};

for (auto const& element : myCollection)
{
    // do something with element
}

Mediator

The design pattern Mediator consists in introducing an object that centralises the logic of interaction between a set of other objects.

The GoF uses the example of a GUI that has many elements that interact with each other. One way to implement this would be to have each class communicate with the others when they need to trigger the appropriate reactions.

But doing this introduces intense coupling, as many objects come to interact with each other.

Mediator mitigates this problem by having all objects notify only one object, the Mediator object, whenever they need to trigger a reaction. The Mediator packages all the logic, and forwards the incoming notifications to the appropriate objects.

As a result, all the objects are connected with the Mediator, instead of all objects being connected with each other.

Seen this way, Mediator is a way to achieve the design principle of Indirection.

Memento

The design pattern Memento helps to restore an object to a previous state.

It works the following way: object A creates a Memento object, and sets in it some information about its current state. The Memento objects is stored somewhere, for example in another object B.

Then A lives on its life, and its state changes.

Later, we give back the Memento object to A, and A retrieves the information that it had put into it. After doing this, A is back to the state it was when it created the Memento object.

B is not concerned with what information is in the Memento object, nor even what kind of information it contains. It just holds it in order for it to be available to eA at a later point.

To which design principle does Memento correspond?

To be honest, I'm not sure Memento relates well to one of the GRASP design principles. What do you think?

We could argue that Memento is about hiding the contents of the state of A. So if we come to modify the program and change the type of state that A needs, B won't be affected. This seems to relate to Low Coupling.

But should we consider that it's part of Protected Variations, in the sense that the Memento object hides the state of A? Or is it another type of Low Coupling?

Observer

(From https://www.fluentcpp.com/2021/10/19/design-patterns-vs-design-principles-observer-state-and-strategy/)

The Observer pattern is about notifications between objects.

Consider an object A that can undergo events, in the general sense of events. That can be GUI events, or changes of state, or anything that could be of interest for another object B. A is called Subject and B is called Observer.

A typical example is indeed for GUI events, for example the user has clicked on a widget. The class handling the GUI event needs to notify the business objects of the program that the event has happened, so that they can react accordingly.

Observer is not limited to GUI though. We can see it at any level of a program. For example, Qt's signals and slots are an implementation of the Observer pattern.

A given Subject can have an arbitrary number of Observers.

A central aspect of the Observer design pattern is that the Subject doesn't know what the Observers are. It just knows that they exist and how to notify them. To implement this aspect, we can use polymorphism, for example with inheritance. The Subject class then must implement the Observer interface (inherited).

The Observer interface could be implemented like this:

class Observer
{
    virtual void onNotification() = 0;
    virtual ~Observer();
};

And the Subject could hold a std::vector<Observer*> (a container of pointers to Observer), and traverse it to call onNotification() on each element, whenever the Subject needs to notify its observers.

State

(From https://www.fluentcpp.com/2021/10/19/design-patterns-vs-design-principles-observer-state-and-strategy/)

The State design pattern is useful when an object can be in several formalized states. The GoF book takes the example of a TCP connection that can be Established, Listening or Closed.

There are many other examples in various fields of objects that can be in several states. For example a financial operation could be PendingApproval, Approved or Closed. Or in a project management application, a task could be ToDo, Doing, ReadyForTesting or Done.

One way to implement this is to have a constant or enum representing each state, and a value that can be equal to either one of the possible states:

enum class TaskState
{
    ToDo,
    Doing,
    ReadyForTesting,
    Done
};

With the task having the following member:

class Task
{
public:
    // ...
private:
    TaskState currentState_;
    // ...
};

This way of representing the state in code can lead to complicated code, with if statements that test the possible values of currentState_. Depending on those values, the if statements would perform actions and/or modify the value of currentState_.

When such code grows in size, it typically grows in complexity. That is to say that this way of coding doesn't scale.

Why? Because it is the same code that handles all of the various possible states and their changes.

The State design patterns aims at solving this problem by representing each state by a type, and not by just the value of an enum:

class ToDo
{
    // ...
};

class Doing
{
    // ...
};

class ReadyForTesting
{
    // ...
};

class Done
{
    // ...
};

Each class owns the code of its corresponding state. Each class also manages the transitions to another state, by instantiating the corresponding class.

The GoF book suggests to have all such state classes inherit from a common base class. This allows to implement state changes by swapping the concrete implementation behind a pointer or reference to the base class.

The State design pattern can also be implemented with templates and phantom types.

Strategy

(From https://www.fluentcpp.com/2021/10/19/design-patterns-vs-design-principles-observer-state-and-strategy/)

The Strategy design pattern consists in letting a calling code use one of several possible algorithms, by hiding them behind an interface.

For example, let's consider a certain task X that has three ways of being accomplished: method A, method B and method C. Rather than having A, B and C directly in the code that needs to perform X, we use three classes that implement the same interface, each one implementing one of the three methods.

class X {
public:
  virtual void doX() = 0;
};
class MethodA: public X {
public:
  void doX() override;
};
class MethodB: public X {
public:
  void doX() override;
};
class MethodC: public X {
public:
  void doX() override;
};

Some other part of the code sets either one of MethodA, MethodB or MethodC as a concrete implementation of the interface.

Even if Strategy allows to achieve cohesion by having each algorithm put away in its own class, it seems to me that the central aspect of Strategy is rather Polymorphism.

Factory method

(From https://www.fluentcpp.com/2022/06/05/design-patterns-vs-design-principles-factory-method/)

To understand what factory method means, let's analyse each of its two words:

• method: this means member function,
• factory: this means something that creates objects.

All this means that a factory method is a member function that creates objects.

It is important to note that this comes from a book on object oriented design (the GoF's Design Patterns book), that makes heavy use of member functions. But my understanding of the design pattern is that it applies beyond member functions. It applies to free functions too. So a more generic and idiomatic name for this design pattern in C++ could be Factory function.

Facade*

The Adapter Design Pattern*

The Strategy Design Pattern*

Template Method

First off, let's mention that the Template Method design pattern has nothing to do with C++ templates. Actually, there is an implementation of this design pattern in C++ that uses templates, but using templates is more an implementation detail rather than the essence of this pattern.

Template Method has even nothing to do with C++ in particular, and can be implemented in other languages that don't support templates.

Template Method consists in having a piece of code that has one or more customisation points.

class Task
{
public:
    void run();
    virtual ~Task() = 0;
private:
    virtual void doTheTask() const = 0;
};

void Task::run()
{
    std::cout << "Task in progress... ";
    doTheTask();
    std::cout << " ...done.\n";
}

class MyTask : public Task
{
private:
    void doTheTask() const override;
};

template <typename Task>
void runTask(Task const& task)
{
    std::cout << "Task in progress... ";
    task.doTheTask();
    std::cout << " ...done.\n";
}

auto myTask = MyTask{};
runTask(myTask);

class MyTask : public Task
{
public:
    void doTheTask() const override;
};