A look at the creational design patterns and their implementation using Modern C++. Covers the Factory design pattern (Factory Method, Abstract Factory) as well as Builder, Prototype, and Singleton. Also covers the SOLID design principles, demonstrates Dependency Injection via Boost.DI, and even shows an example of a Maybe Monad.
Course Overview Hi everyone, my name is Dmitri Nesteruk, and I'm very happy to welcome you to my course on the creational design patterns for the C++ programming language. Now, I am, myself a speaker, a podcaster, a developer, and a technology advocate at Jetbrains. The original design patterns book was written using small talk in C++, so you can consider this course a bit of an update, taking the design patterns into the era of modern C++. This course is an overview of the creational design patterns and the way they're implemented using the C++ language. We begin the course with an overview of the Solid design principles. We take a look at an example of dependency injection, and we even consider a monad, which is a functional design pattern. And then we jump right into the subject matter, talking about the design patterns. So, first comes the Builder, then we talk about the Factory patterns, the Factory method, and the abstract Factory. We then talk about the prototype design pattern, and we finish off the course with the overview of the much maligned, Singleton pattern. By the end of the course, you should know how to implement creational design patterns in C++. Before getting on this course, you should have a reasonably good knowledge of C++. I hope you will join me on this journey to learn design patterns, with the C++ Creational Design Patterns course, here at Pluralsight.
Builder Hi there and welcome to this module on the builder pattern. So, what are we going to see in this module? Well, first of all, we'll talk about what the builder pattern is and the motivation for using the builder pattern in the first place and then we're going to look at how to actually implement the builder pattern in a simple example. Then we're going to take a look at a fluent builder. The notion of using fluent interfaces with builders is very popular in different programming languages and there is no reason why C++ developers should give up on this opportunity. Then we're going to talk about Groovy-style builders. In other words, having a kind of view engine style definition of the kind of things that you're building. And finally, we'll take a look at builder facets, which is a way of actually building different aspects of a complicated object using different builders which are working in tandem with one another.
Factories Hi and welcome to another module in the C+ design patterns creational course. Now in this module we're going to talk about factories. If you're wearing any clothes right now, then chances are your clothes were actually made in a factory, and sure making clothes yourself is quite possible and many people in fact do it as a hobby, but a factory is a kind of centralized location that takes care of the creation of things, whether it's clothing, technological gadgets, or indeed instances of a particular class. In this module we're going to take a look at the factory design pattern and as always, we'll start with discussing the terminology and indeed the motivation for using the pattern in the first place, then we're going to take a look at an example of where the absence of a factory approach makes the API somewhat inconvenient to use, and then we're going to actually refactor our code to adopt the factory approach right inside an existing class, then we're going to expand it to an external class, and we'll also take a look at how to move the factory back into the class that it happens to be creating, and towards the end we're going to look at a more complicated concept related to families of objects and their corresponding families of factories.
Singleton Well, this module is certainly going to be controversial, because what we're going to talk about is the Singleton design pattern, which is one of those patterns which cannot really be considered good practice of modern development, but because it's part of this legacy of design patterns, we're going to talk about it anyway, and we're going to discuss both how it's implemented as well as why you should maybe not use it, or not use it directly. Alright, so I want to sort of start this module with a quote. This was actually from a meeting by the original design pattern authors, the authors of the original book, and when discussing design patterns 15 years later, after the book was published, they said that, for the most part, they would actually keep all the patterns where they are, but when discussing which patterns to drop, as it says here, they found that they love all of them but they're not, they're a bit in favor of dropping the Singleton, because its use is always a design smell, meaning that the use of the Singleton is quite often indicative of an incorrect or inefficient approach to a problem, and we're certainly going to see why this is the case in this module.