Design Patterns in Modern C++

What are SOLID principles, where do they come from and why do we care?

A look at the Single Responsibility Principle, which states that a class should only have one reason to change. Also tied to the concept of Separation of Concerns which is basically stating the same thing.

A discussion of the Open-Closed Principle, which states that classes should be open for extension, but closed for modification. In other words, you should extend functionality using interfaces and inheritance rather than jumping back into already-written/tested code and adding to it or changing it.

This lesson also demonstrates the Specification pattern.

The Liskov Substitution Principle states that subtypes should be substitutable for their base types.

The Interface Segregation Principle is simple: don't throw everything in the kitchen sink into an interface because then all its users will have to implement things they do not need. Instead, split the interface into several smaller ones.

Not to be confused with dependency injection, dependency inversion specifies that high-level modules should not depend on low-level ones; both should depend on abstractions. Confusing, huh?

A summary of the things we've learned in this section of the course.

A brief note about the three categories of design patterns: creational, structural and behavioral.

A discussion of the Builder pattern and what it's used for.

A look at why you'd want to have a builder in the first place.

We implement a simple builder for constructing trees of HTML elements.

We make the builder fluent by returning this from builder methods.

Not so much a Builder pattern, but a clever way of using uniform initializer syntax to create a DSL for easily defining HTML constructs in a familiar manner.

We look at a more complicated builder facade that exposes several sub-builders (builder facets) for building up parts of an object in a fluent manner.

A summary of the things we've learned about the Builder pattern.

A discussion of the general concept of factories and the two design patterns: Factory Methods and Abstract Factory.

A scenario where having a factory interface actually makes sense.

Implementing a factory method, as an alternative to a constructor, is easy.

When you want all the factory methods in a separate class.

An external factory needs the created object's constructor to be public. But what if you want it to be private? There are two solutions here: you either make a friend class or, alternatively, stick a factory into the class whose instance it creates!

Sometimes, you want abstract factories with abstract objects; we support DIP but break OCP in the process.

Thanks to constructs such as std::function, we can express factories in a purely functional way.

A summary of the things we've learned about factories.

A discussion of the Prototype factory (not to be confused with a rather good game of the same name) and what it's used for.

A sample scenario where the Prototype pattern is relevant.

We implement the Prototype design pattern by making copy constructors.

If you find using prototypes a lot, and you need many of them, why not put them into a separate class? Separation of concerns!

One common approach to the Prototype pattern is to serialize-deserialize data. But you need to support it explicitly in each type you use.

A summary of all the things we've learned about the Prototype pattern.

Ahh, the much maligned Singleton... is it really that evil? Let's find out...

Let's put together a simple implementation of Singleton before we start to embellish it with additional traits.

So, what's wrong with the Singleton? Well, hard dependencies on singletons are hard to test.

In order to write a unit test that uses a singleton, we must abstract it away. This is typically done by extracting the singleton's interface and then taking that interface as a dependency (e.g., a constructor parameter). This way, you can supply a fake object instead, thereby getting a true unit test instead of an integration test.

The only socially acceptable way of using a singleton is when you inject it as a dependency. DI containers allow you to configure a singleton lifetime for a component.

The Monostate design pattern is a bizarre variation on the Singleton: it's a type that appears just as an ordinary type (meaning you can construct multiple instances), but all its fields are actually private and static and are exposed with non-static getters and setters. More of a scientific curiosity rather than a viable design solution, this one.

Yet another variation on the Singleton, a Multiton is nothing more than a key-value store with on-demand creation.

A summary of all the things we've learned about the Singleton design pattern.

An overview of the Adapter design pattern.

Let's look at a visual demonstration for a change. This MFC application can only render points, but all we have are lines. We need an adapter!

It just so happens that an adapter generates lots of temporaries. Let's see if we can add some caching to reduce the workload.

A summary of all the things we've learned about the Adapter design pattern.

A look at the Bridge design pattern...

You can simplify the Pimpl idiom with a reusable class.

A summary of all the things we've learned about the Bridge design pattern.

A discussion of what the Composite pattern is for and how it's used.

Let's implement the Composite pattern by considering individual geometric shapes as well as grouping of shapes.

Let's apply the Composite pattern to the implementation of simple neural networks (individual neurons and layers of neurons).

Having individual fields with getters and setters is all fine until you want to perform aggregate operations on all the available fields. This calls for an alternative approach, which is an unusual blend of the Composite and Proxy design patterns.

A summary of all the things we've learned about the Composite design pattern.

An overview of the Decorator design pattern.

The simplest form of Decorator.

Sophisticated decorators which make use of mixin inheritance, constructor forwarding and concepts.

Decorators are typically applied to classes, but it is equally possible to build decorators which wrap arbitrary chunks of code.

A summary of all the things we've learned about the Decorator design pattern.

An overview of the Facade design pattern.

Rather than implementing the Facade from scratch, let's implement it on an existing project!

A summary of the things we learned about the Facade design pattern.

An overview of the Flyweight design pattern.

Let's see how we can implement a simple flyweight by hand.

A ready-made flyweight solution can be found in the Boost libraries. Here's a demo of how to use it, plus we verify that it actually works.

Another example of the Flyweight design pattern, this time applied to the concerns of a text editor.

A summary of all the things we've learned about the Flyweight design pattern.

An overview of the Proxy design pattern.

One example of a Proxy that we all know and love is, of course, the smart pointer classes such as shared_ptr.

A property proxy is a class that can serve as a drop-in replacement for a field but act like a property (i.e., have special getters and setters).

A virtual proxy is a proxy object that lies to you. Basically, it pretends that there is a real, underlying object behind it, whereas in reality, that underlying object might not even exist! One use of a virtual proxy is for lazy loading.

A communication proxy hides away the means of communication. What looks like an in-process call might actually be an RPC or RESTful invocation!

Proxies and decorators look very similar, so what's the difference?

A summary of all the things we've learned about the Proxy design pattern.

An overview of the Chain of Responsibility design pattern.

The simplest Chain of Responsibility is a singly-linked list of pointers. Nothing sophisticated here!

We look at an industry-strength implementation of Chain of Responsibility, which also covers the Mediator, Observer and Command design patterns.