Design Patterns in Modern C++
4.4 (2,751 ratings)
Course Ratings are calculated from individual students’ ratings and a variety of other signals, like age of rating and reliability, to ensure that they reflect course quality fairly and accurately.
15,825 students enrolled

Design Patterns in Modern C++

Discover the modern implementation of design patterns with С++
4.4 (2,751 ratings)
Course Ratings are calculated from individual students’ ratings and a variety of other signals, like age of rating and reliability, to ensure that they reflect course quality fairly and accurately.
15,819 students enrolled
Created by Dmitri Nesteruk
Last updated 11/2019
English [Auto], German [Auto], 6 more
  • Indonesian [Auto]
  • Italian [Auto]
  • Polish [Auto]
  • Romanian [Auto]
  • Spanish [Auto]
  • Thai [Auto]
Current price: $69.99 Original price: $99.99 Discount: 30% off
5 hours left at this price!
30-Day Money-Back Guarantee
This course includes
  • 12.5 hours on-demand video
  • 1 article
  • 83 downloadable resources
  • 21 coding exercises
  • Full lifetime access
  • Access on mobile and TV
  • Certificate of Completion
Training 5 or more people?

Get your team access to 4,000+ top Udemy courses anytime, anywhere.

Try Udemy for Business
What you'll learn
  • Recognize and apply design patterns
  • Refactor existing designs to use design patterns
  • Reason about applicability and usability of design patterns
  • Learn how to use different aspects of Modern C++
Course content
Expand all 130 lectures 12:23:53
+ Introduction
1 lecture 05:38

A taste of things to come... and yes, this is a course on Design Patterns. Join in, it should be a lot of fun!

Preview 05:38
+ SOLID Design Principles
7 lectures 52:08

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.

Preview 06:48

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.

Open-Closed Principle

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

Liskov Substitution Principle

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.

Interface Segregation Principle

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?

Dependency Inversion Principle

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

+ Builder
8 lectures 48:55

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

Gamma Categorization

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.

Life Without Builders

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


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

Fluent Builder

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.

Groovy-Style Builder

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.

Builder Facets
Builder Coding Exercise
1 question

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

+ Factories
8 lectures 36:52

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.

Point Example

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

Factory Method

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!

Inner Factory

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

Abstract Factory

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

Functional Factory
Factory Coding Exercise
1 question

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

+ Prototype
6 lectures 33:24

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.

Record Keeping

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!

Prototype Factory

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

Prototype via Serialization
Prototype Coding Exercise
1 question

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

+ Singleton
8 lectures 39:58

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.

Singleton Implementation

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

Testability Issues

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.

Singleton in Dependency Injection

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.

Singleton Lifetime in DI Container

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.

Singleton Coding Exercise
1 question

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

+ Adapter
4 lectures 20:12

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!

Vector/Raster Demo

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

Adapter Caching
Adapter Coding Exercise
1 question

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

+ Bridge
5 lectures 26:58

A look at the Bridge design pattern...

Pimpl Idiom

You can simplify the Pimpl idiom with a reusable class.

Preview 07:35
Bridge Implementation
Bridge Coding Exercise
1 question

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

+ Composite
5 lectures 33:25

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.

Geometric Shapes

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

Neural Networks

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.

Array-Backed Properties
Composite Coding Exercise
1 question

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

+ Decorator
5 lectures 32:04
Dynamic Decorator

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

Functional Decorator
Decorator Coding Exercise
1 question

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

  • Good understanding of C++
  • Awareness of features of Modern C++ (11/14/17/...)
  • Understanding of OOP (encapsulation, polymorphism, inheritance)

Course Overview

This course provides a comprehensive overview of Design Patterns in Modern C++ from a practical perspective. This course in particular covers patterns with the use of:

  • The latest versions of the C++ programming language
  • Use of modern programming approaches: dependency injection, use of coroutines, and more!
  • Use of modern developer tools such as CLion and ReSharper C++
  • Discussions of pattern variations and alternative approaches

This course provides an overview of all the Gang of Four (GoF) design patterns as outlined in their seminal book, together with modern-day variations, adjustments, discussions of intrinsic use of patterns in the language.

What are Design Patterns?

Design Patterns are reusable solutions to common programming problems. They were popularized with the 1994 book Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, John Vlissides, Ralph Johnson and Richard Helm (who are commonly known as a Gang of Four, hence the GoF acronym).

The original book was written using C++ and Smalltalk as examples, but since then, design patterns have been adapted to every programming language imaginable: Swift, C#, Java, PHP and even programming languages that aren't strictly object-oriented, such as JavaScript.

The appeal of design patterns is immortal: we see them in libraries, some of them are intrinsic in programming languages, and you probably use them on a daily basis even if you don't realize they are there.

What Patterns Does This Course Cover?

This course covers all the GoF design patterns. In fact, here's the full list of what is covered:

  • SOLID Design Principles: Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segregation Principle and Dependency Inversion Principle
  • Creational Design Patterns: Builder, Factories (Factory Method and Abstract Factory), Prototype and Singleton
  • Structrural Design Patterns: Adapter, Bridge, Composite, Decorator, Façade, Flyweight and Proxy
  • Behavioral Design Patterns: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Null Object, Observer, State, Strategy, Template Method and Visitor

Who Is the Course For?

This course is for C++ developers who want to see not just textbook examples of design patterns, but also the different variations and tricks that can be applied to implement design patterns in a modern way.

Presentation Style

This course is presented as a (very large) series of live demonstrations being done in JetBrains CLion. Most demos are single-file, so you can download the file attached to the lesson and run it in CLion, XCode or another IDE of your choice (or just on the command line).

This course does not use UML class diagrams; all of demos are live coding.

Who this course is for:
  • Beginner and experienced C++ software developers
  • Developers interested in implementations of design patterns
  • Computer scientists