Implementing Patterns and Idioms

Design patterns are general reusable solutions that can be applied to common problems that appear in software development. Idioms are patterns, algorithms, or ways to structure the code in one or more programming languages. A great number of books has been written on design patterns. This chapter is not intended to reiterate them, but rather to show how to implement several useful patterns and idioms, with a focus on readability, performance, and robustness, in terms of modern C++.

The recipes included in this chapter are as follows:

• Avoiding repetitive if-else statements in factory patterns
• Implementing the pimpl idiom
• Implementing the named parameter idiom
• Separating interfaces and implementations with the non-virtual interface idiom
• Handling friendship with the attorney-client idiom
• Static polymorphism with the curiously recurring template pattern
• Adding functionality to classes with mixins
...

Avoiding repetitive if-else statements in factory patterns

It is often the case that we end up writing repetitive if...else statements (or an equivalent switch statement) that do similar things, often with little variation and often done by copying and pasting with small changes. As the number of alternative conditions increases, the code becomes both hard to read and hard to maintain. Repetitive if...else statements can be replaced with various techniques, such as polymorphism. In this recipe, we will see how to avoid if...else statements in factory patterns (a factory is a function or object that is used to create other objects) using a map of functions.

Getting ready

In this recipe, we will consider the following problem: building a system that can handle image files in various formats, such as bitmap, PNG, JPG, and so on. Obviously, the details are beyond the scope of this recipe; the part we are concerned with is creating objects that handle various image formats. For...

Implementing the pimpl idiom

pimpl stands for pointer to implementation (also known as the Cheshire cat idiom or the compiler firewall idiom) and is an opaque pointer technique that enables the separation of the implementation details from an interface. This has the advantage that it enables changing the implementation without modifying the interface and, therefore, avoiding the need to recompile the code that is using the interface. This has the potential of making libraries using the pimpl idiom on their ABIs backward-compatible with older versions when only implementation details change. In this recipe, we will see how to implement the pimpl idiom using modern C++ features.

The term ABI stands for Application Binary Interface, and refers to the interface between two binary modules. Typically, one such module is a library or operating system, and the other is a program executed by a user.

Getting ready

The reader is expected to be familiar with smart pointers...

Implementing the named parameter idiom

C++ supports only positional parameters, which means arguments are passed to a function based on the parameter’s position. Other languages also support named parameters – that is, they specify parameter names when making a call and invoking arguments. This is particularly useful with parameters that have default values. A function may have parameters with default values, although they always appear after all the non-defaulted parameters.

However, if you want to provide values for only some of the defaulted parameters, there is no way to do this without providing arguments for the parameters that are positioned before them in the function parameters list.

A technique called the named parameter idiom provides a method to emulate named parameters and help solve this problem. We will explore this technique in this recipe.

Getting ready

To exemplify the named parameter idiom, we will use the control class shown in the...

Separating interfaces and implementations with the non-virtual interface idiom

Virtual functions provide specialization points for a class by allowing derived classes to modify implementations from a base class. When a derived class object is handled through a pointer or a reference to a base class, calls to overridden virtual functions end up invoking the overridden implementation from the derived class. On the other hand, customization is an implementation detail, and a good design separates interfaces from implementation.

The non-virtual interface idiom, proposed by Herb Sutter in an article about virtuality in the C/C++ Users Journal, promotes the separation of concerns of interfaces and implementations by making (public) interfaces non-virtual and virtual functions private.

Public virtual interfaces prevent a class from enforcing pre- and post-conditions on its interface. Users expecting an instance of a base class do not have the guarantee that the expected behavior...

Handling friendship with the attorney-client idiom

Granting functions and classes access to the non-public parts of a class with a friend declaration is usually seen as a sign of bad design, as friendship breaks encapsulation and ties classes and functions. Friends, whether they are classes or functions, get access to all the private members of a class, although they may only need to access parts of it.

The attorney-client idiom provides a simple mechanism to restrict friends access to only designated private members of a class.

Getting ready

To demonstrate how to implement this idiom, we will consider the following classes: Client, which has some private member data and functions (the public interface is not important here), and Friend, which is supposed to access only parts of the private details, for instance, data1 and action1(), but has access to everything:

class Client
{
  int data_1;
  int data_2;
  void action1() {}
  void action2() {}
  friend class Friend...

Static polymorphism with the curiously recurring template pattern

Polymorphism provides us with the ability to have multiple forms for the same interface. Virtual functions allow derived classes to override implementations from a base class. They represent the most common elements of a form of polymorphism, called runtime polymorphism, because the decision to call a particular virtual function from the class hierarchy happens at runtime. It is also called late binding, because the binding between a function call and the invocation of the function happens late, during the execution of the program. The opposite of this is called early binding, static polymorphism, or compile-time polymorphism because it occurs at compile time through functions and operators overloading.

On the other hand, a technique called the curiously recurring template pattern (or CRTP) allows simulating the virtual functions-based runtime polymorphism at compile time, by deriving classes from a base class template...

Adding functionality to classes with mixins

In the previous recipe, we learned about a pattern called the curiously recurring template pattern, or CRTP for short, and how it can be used to add common functionality to classes. This is not its only use; other use cases include limiting the number of times that a type can be instantiated and implementing the composite pattern. Related to this pattern, there is another one called mixins. Mixins are small classes that are designed to add functionality to other existing classes. You can probably find articles about this pattern claiming that it’s implemented using CRTP. That is not correct. Indeed, CRTP and mixins are similar patterns and both are used to add functionality to classes, but they don’t have the same structure. With CRTP, the base class adds functionality to the classes that derive from it. A mixin class adds functionality to a class that it derives from. Therefore, in a way, it is an upside-down CRTP. In this...

Handling unrelated types generically with the type erasure idiom

Polymorphism (and more specifically runtime polymorphism in C++) allows us to treat hierarchies of classes in a generic way. However, there are cases when we want to do the same but with classes that do not inherit from a common base class. This can happen when we do not own the code or, for various reasons, cannot change the code to create a hierarchy. This process of utilizing unrelated types that have some certain members (functions or variables) for given tasks (and only use those common members) is called duck typing. A simple solution to this problem is to build a hierarchy of wrapper classes, one for each class that we want to handle generically. This has drawbacks because there is a lot of boilerplate code and every time a new class needs to be handled in the same manner, a new wrapper must be created. The alternative to this approach is an idiom known as type erasure. The term refers to the fact that information...

Implementing a thread-safe singleton

Singleton is probably one of the most well-known design patterns. It restricts the instantiation of a single object of a class, something that is necessary in some cases, although many times the use of a singleton is rather an anti-pattern that can be avoided with other design choices.

Since a singleton means a single instance of a class is available to an entire program, it is likely that such a unique instance might be accessible from different threads. Therefore, when you implement a singleton, you should also make it thread-safe.

Before C++11, doing that was not an easy job, and a double-checked locking technique was the typical approach. However, Scott Meyers and Andrei Alexandrescu showed, in a paper called C++ and the Perils of Double-Checked Locking, that using this pattern did not guarantee a thread-safe singleton implementation in portable C++. Fortunately, this changed in C++11, and this recipe shows how to write a thread-safe...