Patterns Cplusplus

Tags:

Discover the modern implementation of design patterns with С++

Last updated 2022-01-10 | 4.5

- Recognize and apply design patterns
- Refactor existing designs to use design patterns
- Reason about applicability and usability of design patterns

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++

* Requirements

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

Description

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

Course content

25 sections • 150 lectures

Introduction Preview 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!

Overview Preview 00:52

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

Single Responsibility Principle Preview 06:48

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.

Open-Closed Principle Preview 14:51

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.

Liskov Substitution Principle Preview 07:17

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

Interface Segregation Principle Preview 06:33

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.

Dependency Inversion Principle Preview 13:21

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?

Summary Preview 02:26

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

Gamma Categorization Preview 03:36

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

Overview Preview 01:43

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

Life Without Builders Preview 03:50

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

Builder Preview 06:40

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

Fluent Builder Preview 09:02

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

Groovy-Style Builder Preview 08:12

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.

Builder Facets Preview 14:55

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 Coding Exercise

Summary Preview 00:57

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

Overview Preview 03:20

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

Point Example Preview 04:05

A scenario where having a factory interface actually makes sense.

Factory Method Preview 04:00

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

Factory Preview 03:59

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

Inner Factory Preview 04:02

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!

Abstract Factory Preview 12:25

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

Functional Factory Preview 03:46

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

Factory Coding Exercise

Summary Preview 01:15

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

Overview Preview 01:59

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.

Record Keeping Preview 06:33

A sample scenario where the Prototype pattern is relevant.

Prototype Preview 05:02

We implement the Prototype design pattern by making copy constructors.

Prototype Factory Preview 07:09

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 via Serialization Preview 11:33

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 Coding Exercise

Summary Preview 01:08

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

Overview Preview 02:43

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

Singleton Implementation Preview 06:52

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

Testability Issues Preview 05:04

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

Singleton in Dependency Injection Preview 06:24

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 Lifetime in DI Container Preview 05:40

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.

Monostate Preview 02:49

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.

Multiton Preview 08:36

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

Singleton Coding Exercise

Summary Preview 01:50

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

Overview Preview 02:36

An overview of the Adapter design pattern.

Vector/Raster Demo Preview 09:12

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!

Adapter Caching Preview 07:14

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 Coding Exercise

Summary Preview 01:10

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

Overview Preview 01:46

A look at the Bridge design pattern...

Pimpl Idiom Preview 08:54

Shrink-Wrapped Pimpl Preview 07:35

You can simplify the Pimpl idiom with a reusable class.

Bridge Implementation Preview 08:22

Bridge Coding Exercise

Summary Preview 00:21

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

Overview Preview 01:53

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

Geometric Shapes Preview 04:34

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

Neural Networks Preview 15:19

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

Array-Backed Properties Preview 09:37

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.

Composite Coding Exercise

Summary Preview 02:02

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

Overview Preview 01:46

An overview of the Decorator design pattern.

Dynamic Decorator Preview 09:32

The simplest form of Decorator.

Static Decorator Preview 12:10

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

Functional Decorator Preview 11:18

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

Decorator Coding Exercise

Summary Preview 01:07

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

Overview Preview 03:08

An overview of the Facade design pattern.

Façade Preview 08:42

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

Summary Preview 01:25

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

Overview Preview 02:21

An overview of the Flyweight design pattern.

Handmade Flyweight Preview 09:34

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

Boost.Flyweight Preview 03:34

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.

Text Formatting Preview 11:04

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

Flyweight Coding Exercise

Summary Preview 00:42

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

Overview Preview 02:07

An overview of the Proxy design pattern.

Smart Pointers Preview 03:32

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

Property Proxy Preview 04:55

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).

Virtual Proxy Preview 04:46

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.

Communication Proxy Preview 05:47

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

Proxy vs Decorator Preview 01:18

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

Proxy Coding Exercise

Summary Preview 00:46

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

Overview Preview 03:33

An overview of the Chain of Responsibility design pattern.

Pointer Chain Preview 11:13

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

Broker Chain Preview 12:22

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

Chain of Responsibility Coding Exercise

Summary Preview 02:03

A summary of all the thing we've learned about the Chain of Responsibility design pattern.

Overview Preview 05:28

An overview of the Command design pattern.

Command Preview 06:42

Let's take a look at how to implement the Command design pattern!

Undo Operations Preview 05:39

A command modifies state. And so it can undo its own change!

Composite Command (Macro) Preview 10:53

macro is a command consisting of other commands. This is the Composite design pattern... for commands. Let's implement it!

Command Coding Exercise

Summary Preview 01:09

A summary of all the things we've learned about the Command design pattern. Still alive.

Overview Preview 04:14

An overview of the Interpreter design pattern.

Handmade Interpreter: Lexing Preview 08:05

The first part of the interpretation is the separation of input into lexical tokens, a.k.a. lexing.

Handmade Interpreter: Parsing Preview 12:23

The second part of interpretation is the transformation of tokens into an object-oriented structure, a.k.a. parsing.

Building Parsers with Boost.Spirit Preview 09:40

Buiding parsers by hand is a bit tedious. Let's take a look at a real-life example of a programming language built using the Boost.Spirit parser framework.

Interpreter Coding Exercise

Summary Preview 01:16

A summary of the Interpreter design pattern.

Overview Preview 01:37

An overview of the Iterator design pattern.

Iterators in the Standard Library Preview 11:09

A look at how iterators are exposed by standard library types such as std::vector.

Binary Tree Iterator Preview 13:46

We construct an iterator for a binary tree.

Tree Iterator with Coroutines Preview 05:51

Our binary tree iterator code is really messy because ordinary operator++ implementations cannot possibly use recursion, and tree traversal algorithms are typically recursive. Coroutines to the rescue!

Boost Iterator Façade Preview 05:38

A look at a Boost component that helps us make iterators.

Iterator Coding Exercise

Summary Preview 01:39

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

Overview Preview 01:13

An overview of the Mediator design pattern.

Chat Room Preview 16:37

The chat room is a classic example of a Mediator. Well, let's build one!

Event Broker Preview 08:18

An event broker is a Mediator that also implements the Observer design pattern.

Mediator Coding Exercise

Summary Preview 01:16

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

Overview Preview 01:41

An overview of the Memento design pattern.

Memento Preview 06:16

The Memento pattern is really easy to implement: simply save all relevant state of the system as a set of private fields, then return the object. Don't forget to make the memento accessible to whichever class will be using it!

Undo and Redo Preview 10:15

What if you were to save every single memento that the system generates? Then you'd be in a perfect position to get undo/redo functionality for free!

Automatic Memento Preview 05:49

An automatic memento is a memento that, instead of being used to restore the state of the system at a particular time, causes the restoration of the system as soon as it goes out of scope (i.e., in its destructor).

Memento Coding Exercise

Summary Preview 01:44

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

Overview Preview 02:20

An overview of the Observer design pattern.

Observer Preview 04:14

We start by implementing the Observer<T> interface.

Observable Preview 07:01

Objects to be observed need to explicitly support observers, which leads to the creation of the Observable<T> interface.

Observable with Boost.Signals Preview 04:55

We look at a ready-to-use observable implementation from the Boost.Signals2 library.

The Problem of Dependencies Preview 04:37

If properties depend on other properties, getting the Observable paradigm to work is really difficult!

Thread Safety and Reentrancy Preview 09:57

What happens if the observable is used from multiple threads? What happens if we try to unsubscribe from within an observable handler function?

Observer Coding Exercise

Summary Preview 01:35

And I'm glad I got burned, let's discuss the things we've learned... about the Observer design pattern.

Overview Preview 03:08

An overview of the State design pattern.

Classic State Implementation Preview 09:10

A look at a classic and, admittedly, somewhat bizarre, implementation of a state machine.

Handmade State Machine Preview 08:47

Let's see how we can hand-roll a more sensible state machine.

State Machine with Boost.MSM Preview 11:59

Let's use an industry-grade Boost.MetaStateMachine framework for building a more sophisticated state machine!

State Coding Exercise

Summary Preview 01:52

A summary of all the things we've learned about the State design pattern and state machines.

Overview Preview 01:50

An overview of the Strategy design pattern.

Dynamic Strategy Preview 09:23

We implement the Strategy pattern in a dynamic way, which allows the switching of strategies at runtime.

Static Strategy Preview 02:11

We change our implementation of the Strategy so that it can be determined only at runtime (as a template argument).

Strategy Coding Exercise

Summary Preview 00:26

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

Overview Preview 01:29

An overview of the Template Method design pattern.

Template Method Preview 06:33

Let's go ahead and implement a Template Method, shall we?

Template Method Coding Exercise

Summary Preview 00:31

A summary of the things we've learned about the Template Method design pattern.

Overview Preview 03:18

An overview of the Visitor design pattern.

Intrusive Visitor Preview 07:30

Assuming you're comfortable with modifying the hierarchy of objects, you can just add another virtual method into the entire hierarchy and implement it in each class. This approach breaks both OCP and SRP!

Reflective Visitor Preview 06:47

C++ is not able to choose an overload to dispatch on at runtime. It needs to know the type straight away. So instead of a set of overloads, we can respect SRP with a separate printer class, but we're bound to have lots of dynamic_cast's and if statements.

Classic Visitor (Double Dispatch) Preview 16:58

A classic visitor, with an illustration of the double-dispatch approach.

Acyclic Visitor Preview 13:19

An acyclic visitor is an alternative to the GoF visitor. It trades performance away for a greater amount of flexibility w.r.t. inheritance hierarchies. Unlike the classic visitor, which is based on function overloading, an acyclic visitor is based on RTTI.

Multimethods Preview 12:19

We did a double dispatch based on a single function argument. What if you need to dispatch on two (or more) arguments?

Well, this is a problem. So we'll take a look at a possible solution, not related to visitor per se.

Variant and std::visit Preview 08:38

A look at how visitors are built for the std::variant type.

Visitor Coding Exercise

Summary Preview 01:20

A summary of the Visitor design pattern.

End of Course Preview 01:01

We've reached the end of the course! But there's always cake! Thanks for taking part!