This course provides a comprehensive overview of Design Patterns in C# and .NET from a practical perspective. This course in particular covers patterns with the use of:
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 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:
Who Is the Course For?
This course is for .NET/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. For example, the introduction of the DLR allows us to use an ImpromptuObject, so that our DynamicObject exposes any interface we desire. This allows for dynamic programming, and many design patterns are presented in terms of their static and DLR-based variations.
This course is presented as a (very large) series of live demonstrations being done in Microsoft Visual Studio. Most demos are single-file, so you can download the file attached to the lesson and run it in Visual Studio, Visual Studio Code, Rider or another IDE of your choice.
This course does not use UML class diagrams; all of demos are live coding. I use Visual Studio, various NuGet packages, R# unit test runner and even dotMemoryUnit.
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.
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 discussion of the Builder design 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.
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 Method and Abstract Factory.
A scenario where having a factory interface actually makes sense.
Implementing a factory method is easy, and you can turn a constructor into a factory method using ReSharper.
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? The solution is simple: stick a factory into the class whose instances it creates!
Sometimes, you want abstract factories with abstract objects; we support DIP but break OCP in the process.
Can we fix an OCP violation without introducing an IoC container? Seems we can.
A summary of the things we've learned in this module.
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.
The .net Framework comes with an
ICloneable interface but its use is not recommended. Why not?
Another suspect approach from the land of C++. While it avoids the confusion of ICloneable, it's not clear-cut either. Plus, we still have to do things recursively, which is tiring.
If you don’t like the ambiguity of
ICloneable, why not make your own interface that has a
How to make a copy of the entire object graph without writing any copy-specific code? Easy, just serialize and deserialize!
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...
Avoiding all the philosophical nonsense surrounding double-checked locking (it’s not thread-safe) and implementations involving inner static classes (with an empty
static constructor to avoid
beforefieldinit), we simply look at a safe .net 4-like way of making a lazy, thread-safe singleton.
The singleton works fine, so what's the problem? Turns out, hard reference to a type means we cannot fake it in our tests. Oops!
The only socially acceptable way of using a singleton is with a DI framework.
Typically, marking a component as a singleton is trivial. Check out my Dependency
Injection course! (link below)
A variation on a Singleton pattern, the Monostate lets the client instantiate as many copies of the singleton class as they want, but all those copies refer to the same
static data. Is this a good idea? Let’s find out!
A summary of all that we've learned about the Singleton. As you can see, it's not really that evil provided it can be substituted by a different type (polymorphism). Also, lifetime management is best left to a specialized system (i.e. a DI container).
A look at the Adapter design pattern.
We are going to build a simple adapter for the rending of vector data where only a raster renderer is available.
An adapter can generate a large number of temporary objects. Caching helps us avoid doing extra work more than once.
A summary of all the things we've learned about the Adapter pattern.
A discussion of the Bridge pattern and what it's used for.
A simple illustration of how to build a bridge.
A summary of all the important things we've learned in this section of the course.
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).
A summary of all the things we've learned about the Composite design pattern.
A look at the Decorator design pattern.
StringBuilder is unfortunately sealed. Let's see how we can have its de facto inheritor as a Decorator.
Here we build a pattern which is both a decorator (over a StringBuilder) and an adapter (adapting string's operator support).
When you implement pseudo-multiple inheritance using interfaces, you quite often end up implementing the Decorator pattern.
A look at how to make decorators-of-decorators.
Can decorators be composed as nested generic type arguments? They can, but things aren't as rosy in .NET as they are in C++.
A summary of all the things we've learned about the Decorator design pattern.
Dmitri Nesteruk is a developer, speaker and podcaster. His interests lie in software development and integration practices in the areas of computation, quantitative finance and algorithmic trading. His technological interests include C#, F# and C++ programming as well high-performance computing using technologies such as CUDA. He has been a C# MVP since 2009.
Dmitri is a graduate of University of Southampton (B.Sc. Computer Science) where he currently holds a position as a Visiting Researcher. He is also an instructor on an online intro-level Quantitative Finance course, and has also made online video courses on CUDA, MATLAB, D, the Boost libraries and other topics.