Design Patterns in C++: Structural - Adapter to Decorator

Course Overview
Hi everyone, my name is Dmitri, and welcome to my course on the Structural C++ Design Patterns -- Adapter to Decorator. So I am, myself, a quantitative analyst, but also very interested in tech, and using plenty of C++, and this course is about design patterns. It's actually part of a series of courses on C++ design patterns, and so in this course we're going to consider the first half of the structural design patterns, starting at adapter and ending with decorator. Now to be specific, the topics that we're going to cover are four distinct patterns, so that's adapter, bridge, composite, and decorator, and for all of these we're going to consider both the classical implementations of those patterns, as well as the different variations, the ways in which modern C++ can help us implement those patterns. So by the end of this course you should become very comfortable actually using these patterns and applying them in your development practices. Now before beginning this course you should already be familiar with C++, with object-oriented programming, but apart from that there are no real requirements, so all of the stuff that we're going to talk about is basically building upon the object-oriented building blocks. So after finishing this course, you can also check out the other courses in this C++ Design Patterns series, as well as other general purpose C++ courses. So I hope you'll join me on this journey to learn about the structural design patterns with this course here on Pluralsight.

Bridge
Welcome to the second module of this course. In this module, we're going to take a look at the bridge design pattern, and as always we'll follow the typical structure which you've seen in the other modules in this course. We'll first of all talk about the motivation for actually using the bridge design pattern in the first place. Then we're going to take a look at the PIMPL idiom, and the PIMPL idiom provides a good setup for discussing the bridge pattern, even though it is by itself another pattern which is used for different reasons, and it's certainly not a part of the Gang of Four patterns. We're still going to discuss it because there are certain similarities, and you can think of the bridge pattern as a kind of extended version of the PIMPL idiom with some of the restrictions removed. And then finally, we'll take a look at an actual example of setting up the bridge pattern by looking at geometric shapes and the way that you go about sizing them.

Composite
Hello, and welcome to the third module in this course. Now, in this module we're going to talk about the composite design pattern. so what are we going to talk about specifically? Well, first of all, as always we're going to look at the motivation for using this design pattern, and then we'll talk about the idea of object composition, generally how to compose objects, and what consequences this has if those objects are related in some sort of hierarchy, perhaps, and then we'll take a look at two worked out examples. So the first example will involve simple geometric shapes and grouping those shapes into groups, effectively, and how you can actually work with drawing those shapes if they're part of a group, and then we'll take a look at an example of neural networks and the way that you can model individual neurons, but also model layers of neurons, and how these different constructs can connect to one another.

Decorator
Hi there. In this module, we'll talk about the Decorator design pattern. So what are we going to talk about? Well, as always we'll start with the motivation for using decorators. Then we'll take a look at function decorators first of all, and this is something that is not directly related to the object-oriented structure of the decorator pattern, but it is present in programming languages such as Python, for example, therefore it's interesting to discuss before we delve into the object-oriented part of things. Then we're going to talk about one approach to making decorators, a wrapping decorator, which is not so flexible and not so usable, however, it does have the advantage of being a runtime-capable decorator, meaning that this is the kind of decorator you can build at runtime while the program is running, dynamically, and so it is very flexible in this regard. However, our better implementation of the decorator pattern is going to be a static implementation that uses the notion of Mixin inheritance, so we're going to implement this pattern and see how to work with it. And finally, we're going to make some improvements to this pattern, to this Mixin inheritance approach, by adding functionality for, first of all, some verification of template parameters, and we'll also make the constructors a bit easier to use.