The design patterns library contains descriptions and examples of software design patterns that you can apply in your daily development. These patterns are time proven techniques for building long-lived, well factored software that are widely used in software development today. Unlike other courses in our library, this course will continue to grow with new patterns each month, so check back often.
David Starr is Director of Technical Learning at GoDaddy, Inc. He specializes in agile software development practices, patterns and practices, and judicious application of various technologies within development teams. He is a 5 time Microsoft MVP in Visual Studio and a technical instructor with Pluralsight where he focuses on the software development practices and developer tooling curricula. David blogs at ElegantCode.com, is a frequent contributor at conferences and a frequent writer. He has successfully led many product development teams and is a technical learning professional.
Robert spent nearly 10 years at Microsoft creating software that made it easier for everyone else to write software. Most recently Robert worked on Team Foundation Server on the Administration and Version Control teams. Currently Robert can be found working in the utilities sector on Smart Grid technologies.
Keith is a co-founder of Pluralsight, serving as CTO through 2014, where he helped build the initial content delivery system for Pluralsight, then focused on hiring an awesome team of developers in Utah to take it to the next level.
Brian Lagunas is a Microsoft MVP, a Microsoft Patterns & Practices Champion, Director of Technology for INETA, co-leader of the Boise .Net Developers User Group (NETDUG), board member of Boise Code Camp, speaker, trainer, author, and original creator of the Extended WPF Toolkit.
Glenn is a PM on the WCF team working on Microsoft’s future HTTP and REST stack. Prior to WCF he was a PM on the new Managed Extensibility Framework in .NET 4.0. He has experience both inside and outside Microsoft developing software solutions for ISVs and the enterprise. He has also been active in involving folks from the community in the development of software at Microsoft. This has included shipping products under open source licenses, as well as assisting other teams looking to do so.
Niraj works as an Enterprise Architect for a Fortune 500 company and has an innate passion for building / studying software systems. He is also a manager/speaker at BDOTNET, India’s largest .NET user group.
Donald Belcham is a senior software developer, independent contractor, and agile development expert who is a strong supporter of fundamental OO patterns and practices. Since 2007, he has been awarded the Microsoft MVP Award in C# and is a member of the JetBrains Academy.
John Brown is a Software Craftsman continually looking for intuitive
designs, agile architectures, and streamlined processes. With degrees in
Computer Science from Johns Hopkins and Aerospace Engineering from Purdue,
John is always up for a challenge, especially in his areas of interest in
Artificial Intelligence and Machine Learning.
Scott has over 15 years of experience in commercial software
development and is a frequent speaker at national conferences,
and local user groups. Scott is a Microsoft MVP and has authored
books on several Microsoft technologies, including ASP.NET, C#,
and Windows Workflow.
Introduction to Design Patterns Hello. This is David Starr, and in this module we're going to discuss the idea of design patterns, and specifically, how Pluralsight means to present design patterns to you in our Pluralsight Design Pattern Library. And in this module's discussion we'll be covering what in the world these design patterns are in the first place. Why should I care about this? Where the idea of design patterns originated, a little bit of the history of where design patterns come from. And also, why we should care. Why do design patterns matter, and are they worth my time? Should I pay attention to these things? And finally, we'll look at some specifics on the Pluralsight OnDemand! Pattern Library.
Adapter Pattern This is Steve Smith. Welcome to another Pluralsight On Demand module. This is part of the Design Patterns Library, and today we're going to have a look at the Adapter Pattern.
Bridge Pattern Hi. This is John Sonmez from Pluralsight, and in this module we're going to be talking about the Bridge Pattern. The Bridge Pattern is one of those design patterns that I think a lot of people find pretty difficult to understand, and understandably so. The Bridge Pattern has quite a few different components to it, and it's sometimes difficult to find good examples of when to use the Bridge Pattern, and it can be a little bit confusing to grasp this concept. But in this module, we're going to try and simplify this as best as possible so that it'll be real easy for you to understand exactly what the Bridge Pattern is, and when you should use it. So, we're first going to talk a little bit about a general case of using the Bridge Pattern, and we're going to see how in a real life situation the Bridge Pattern might apply. And then we're going to go through some code, and we're going to refactor that code to use a Bridge Pattern, and we'll see how doing so is going to reduce our code, and make our code much more maintainable. Then finally, we're going to wrap it up by looking at the actual UML diagrams of the Bridge Pattern, and see how we had implemented that pattern in our code, so let's go ahead and dive right in and learn about the Bridge Pattern.
The Command Pattern Hi. My name is Keith Brown. I'm a cofounder of Pluralsight. com and I'm here to tell you a little bit about one of my friends, the Command Pattern. This very simple little pattern can be used in everything from websites implementing complicated features like Undo, to implementing very simple features, like command-line Parsing in a Console application.
Composite Pattern Hi. This is John Sonmez from Pluralsight, and in this module we're going to be talking about the Composite Pattern. The Composite Design Pattern is actually a pretty simple pattern to understand. It's not really that difficult like some of the other design patterns. But the trick with the Composite Pattern is knowing when to use it, and knowing how to properly use it to make it so that your code to iterate through collections, and to handle trees is reduced. In this module, we're going to go ahead, and we're going to look at the Composite Pattern, generally what it is, and breakdown the definition of the Composite Pattern. Then, we'll go ahead and see some examples of the Composite Pattern, first one in real life, and then we'll look at one in the code, and we'll see how we can refactor our code to use the Composite Pattern, and really simplify that code. Than finally, we'll take a look at the UML diagram of what we've created, and we'll discuss some ways that you can recognize the need for using the Composite Pattern in your day-to-day code.
Decorator Design Pattern Hello. This is Brian Lagunas, and in this module, I'm going to discuss the Decorator Design Pattern. The Decorator Design Pattern is a structural pattern which is used to extend, or alter the functionality of objects at runtime. It does this by wrapping them in an object of a Decorator class, leaving the original object intact without modification. I recently worked on a legacy application in which there was no client side validation. I used the Decorator Design Pattern to add validation to all client-side objects without modifying the existing code structure. This allowed me to not break anything, yet at the same time add the required functionality.
Event Aggregator Hello. My name is Glenn Block, and I'm going to talk to you today about the Event Aggregator Pattern.
Facade Pattern Hello. This is David Starr, and welcome to this module on the Facade Design Pattern. I like the Facade Pattern because it's rather fun to learn as we go through the formal expression of the Facade Pattern, that what it proposes is probably something that you've been doing as a developer for years without even thinking about it. It's just kind of nice to know that this thing that I do naturally as a developer, it actually has a name.
Factory Patterns Hello this is David Starr, and in this module from our Design Patterns Library, we'll be taking a look at Factories. We're going to look at several different types of factories, including a very simple factory that doesn't necessarily conform to the patterns that were laid out by the original Gang of Four book, or subsequent books on the subject. We'll take a look at the Factory method. This is the more formal expression of the software factory, and finally the Abstract Factory Pattern.
Flyweight Hi. My name is Niraj. In this module we'll walk through the Flyweight Pattern. Many people consider Flyweight to be a creational pattern, as it revolves around use of a Factory. But the major focus of the pattern is on structuring objects so that they can be shared across multiple contexts. This module will help you understand the Flyweight Pattern, showing you how you can leverage it across UI applications. Let's get started by looking at its intent.
Interpreter Pattern Hi! This is John Sonmez from Pluralsight, and in this module we are going to be talking about the Interpreter Design Pattern. The Interpreter Design Pattern is a different kind of design pattern. It doesn't fit in with a lot of the other design patterns, and a lot of people are confused by this. This is one of those patterns that's pretty easily overlooked, and people don't tend to really understand how it works. But, by the end of this module, my hope for you is that you will have a solid understanding of the Interpreter Pattern, and know exactly how you can both apply this, and implement this.
Iterator Pattern Hi. This is Steve Smith, and in this Pluralsight module, we're going to take a look at the Iterator Design Pattern. Let's start by considering the motivating example for why we need to have an Iterator Pattern. Imagine that you work with a number of different collection, or aggregate types, and you need to be able to traverse these different types of collections, preferably without knowing about their internal structures. You also don't want every collection to have to be bloated with an interface that allows you to traverse it. What the Iterator Pattern allows you to do is abstract away the actual iteration from the collection itself, giving you a way to access the collections members sequentially without violating its encapsulation, or SRP, the Single Responsibility Principle.
Lazy Load Pattern Hi. This is Steve Smith, and in this Design Patterns module we're going to examine the Lazy Load Pattern. The Lazy Load Pattern is generally used to increase the performance of an application by reducing the amount of work it needs to do, when that work is unnecessary. Let's get started!
Mediator Pattern Hi, this is Donald Belcham, and in this Pluralsight on-demand video we are going to look at the Mediator Pattern.
Memento Hi, this is Steve Smith with Pluralsight on-demand and in this video we'll take a look at the Memento Design Pattern. Memento is a useful pattern for implementing Undo/Redo functionality in your applications. Let's get started. Let's first consider a motivating example for the Memento Pattern. This example is basically meant to show you when you would want to consider using the Memento Design Pattern within your application. The classic case for the Memento is when you want to provide some kind of a rollback or Undo functionality to an object or to your entire application. Adding Undo functionality directly to classes within your application would violate the Single Responsibility Principle, since presumably those objects already have other responsibilities. You can learn more about the Single Responsibility Principle in the Principles of Object Oriented Design Course available on Pluralsight. You also don't want to simply provide access to an objects internal state, as this would violate Encapsulation. Instead, you can use the Memento Pattern in order to capture that object's internal state without violating Encapsulation or the Single Responsibility Principle or SRP.
Model View Presenter (MVP) Pattern Hello, my name is David Starr, and in this module we're going to be talking about the Model View Presenter or MVP Design Pattern. Now this design pattern is intended to be used in applications where we have a user interface and this pattern is designed to help us separate various components of our user interface so that we don't end up with those giant code-behind files that we might be used to in Windows Forms or Web Forms applications. This pattern is very popular and especially so with Microsoft developers because the two technologies we just discussed, Windows Forms and Web Forms, those two technologies benefit a great deal from using the Model View Presenter Pattern, and as such, this pattern has a fairly long history, not just within the Microsoft stack. One thing you'll find is that there is a lot of opinion, there are a lot of different variations about how to best implement this pattern, and what we're going to try and do here is show you how we implement the pattern on Pluralsight. com, because we know that that particular style or variation of implementation works pretty well for us. Now we will cover some of the other ways that the pattern can be implemented, but we'll focus on a very simple model that we use here at Pluralsight.
Model View ViewModel (MVVM) Pattern Hello, this is Brian Lagunas, and in this module I'm going to discuss the Model-View-ViewModel, otherwise known as the MVVM Design Pattern. The Model-View-ViewModel Design Pattern facilitates modern development techniques such as separation of concerns, unit testing, and test-driven development. I have had great success with the Model-View-ViewModel Design Pattern. Notably I was part of a team that about a year and a half ago created an application that tracks the progress of construction at the erection site. The project was completed on time, and over the span of that year and a half has had only two reported bugs, and that was partly due to the fact that we used the Model-View-ViewModel Design Pattern to construct the application. As with most Design Patterns, the Model-View-ViewModel Design Pattern is just a set of guidelines that when you follow them it makes it easier to write applications. Use them where they make sense and modify them to fit the needs of your application at a given point in time. We're going to start off by talking about where the Model-View-ViewModel Design Pattern came from, who created it. Then we'll discuss what is the Model-View-ViewModel Pattern, the different components, what those components are, and how they interact with each other. And then we'll also see how to implement this pattern in your own applications.
Null Object Pattern Hello this is David Starr, and in this module we're going to be looking at Null Object Design Pattern. I personally have found this pattern to be very helpful in making my code just cleaner and easier to read, and I can tell you that we use this pattern extensively in the Pluralsight. com website and we've found that it just really helps our code be more maintainable.
Observer Pattern Hello. This is John Brown, and in this module from our Design Patterns Library we will be looking at the Observer Pattern. This pattern is widely used in software development and may be used in some places that you may not be aware of. To get an understanding of when to use the Observer Pattern, we'll take a look at an example where we can apply the Observer Pattern to make the code more in alignment with the solid principles. I will then introduce you to the Observer Pattern and we'll talk about what makes up the Observer Pattern. We'll follow on by discussing three variations of the pattern starting with the traditional version that was documented by the Gang of Four in their Design Patterns book. We'll also look at Events and Delegates, the bread and butter of the Observer Pattern in the. NET framework. And we'll take a look at a new implementation of the Observer Pattern that was added to the. NET framework in version 4. Finally, we'll talk about some real world examples and some of the pitfalls to avoid when interacting with them. So when do we want to use an Observer Pattern? As the name implies, the Observer Pattern is useful when one object is dependent on the changes in another object. Instead of periodically checking to see if the object has changed, we would only like to be notified when it changes. We also look to the Observer Pattern when we do not know how many other classes or instances are monitoring the changes to the object. And probably most importantly, when the concerns of one class or instance are unrelated and/or need to be hidden from the other classes or instances monitoring the object, we can implement the Observer Pattern to handle the communications independently.
Proxy Pattern Hi, this is Steve Smith, and in this Pluralsight on-demand module we're going to take a look at the Proxy Design Pattern.
Repository Hi, this is Scott Allen of Pluralsight, and in this module we're going to look at the Repository Pattern. This is a common design pattern inside of applications that need to perform data access. Why do we use the Repository Pattern? Because most applications do need to access data from some Data Source or perhaps multiple Data Sources, and it doesn't matter if those Data Sources are relational databases like SQL Server or web service endpoint or a collection of text files on the file system, what we don't want to do is duplicate data access code throughout our Business Logic or our Domain Model. Typically data access code is very repetitive and it's concerned with low-level infrastructure details like opening SQL connections and managing SQL parameters and transactions. We don't want that sort of code duplicated throughout our Business Logic. What we'd like to do is extract that so that the Business Logic is just focused on implementing the special algorithms that make the business work. We'd like to extract the data access code so that we have a separation of concerns and we have a separate layer of code that's concerned with accessing this Data Source. This also increases the testability of an application, because as we're about to discover using the Repository Pattern, we can simulate data access when we're inside of unit tests and actually have a component that works with in-memory data instead of a web service or against a database schema. This allows our unit test to be very repeatable, very low friction, and not much effort to set up, and it also lets those unit tests run very fast so that we have a quick feedback cycle.
Singleton Hi this is Steve Smith, and in this Pluralsight module we're going to have a look at the Singleton Design Pattern. This is part of the Design Patterns Library, and Singleton is one of the simplest design patterns, but it's also an easy one to get wrong if you're not careful.
Service Locator Pattern Hi, this is John Brown, and this is another module in the Design Patterns Library. In this module we'll review the Service Locator Pattern and when and how to implement the Service Locator Pattern to simplify the code, provide separate responsibilities, and increase maintainability. The Service Locator Pattern is a creational pattern that was identified, not as part of the Gang of Four's creational patterns, but rather identified more as a pattern that was in use by Enterprise applications to help clients find services on remote servers. We see it referenced in the Core J2EE work on the Business Tier. With the advent of Inversion of Control Containers, we see the Service Locator referenced more and more. Containers such as Spring. NET, StructureMap, Ninject, and Castle Windsor, provide object construction that helps to decouple the calling class from the dependent object. The implementation of an IoC Container is typically done using either a Factory Pattern, Dependency Injection or a Service Locator.
State Pattern Hi, this is John Brown, and this is another module in the Design Patterns Library. In this module, we'll review the State Pattern, and when and how to implement the State Pattern to simplify the code, provide separate responsibilities, and increase maintainability. Behavioral design patterns help us write code that can adapt to the situation. The patterns listed here were first documented by the Gang of Four in the early 1990s. Some patterns help in communicating between two objects, such as the Chain of Responsibility, the Command, and the Mediator Patterns. Other patterns change how the actions or the methods of an object behave based on configuration, such as the Strategy Pattern. The State Pattern, however, allows the object to change the method's behavior, not through configuration, but based on the state of the object. Let's take a look at a simple example of where the complexities of managing the different branches of logic within methods, can quickly become overly complicated.
Strategy Pattern Hello my name is David Starr, and today we're going to be talking about the Strategy Pattern. Now the Strategy Pattern is arguably one of the simpler Design Patterns we might encounter in the world of Design Patterns, and it's a great place to get started if you're just introducing yourself to this idea of common patterns of Object Oriented Software Design. Now the Strategy Pattern is also very practical. I find a lot of uses for it in day-to-day coding, and it can really help us clean up some of our existing designs. Let's jump right in by taking a look at an example of why we might want to use the Strategy Pattern.
Template Method Hi, this is Steve Smith, and in this Pluralsight on-demand video we're going to have a look at the Template Method Design Pattern.
Visitor Pattern Hi, this is John Sonmez from Pluralsight, and in this module we're going to be talking about the Visitor Design Pattern. The Visitor Design Pattern is one of my favorite design patterns. I think it's a very useful design pattern, and it is also one of the design patterns that isn't used as much as it should be. I find that a lot of people find the Visitor Pattern to be complex or it looks complex when you look at the UML diagrams, and so they tend to avoid it, but hopefully by the end of this module you'll have a good understanding of how to use the Visitor Pattern and how to apply it as we walk through some examples. First we're going to look at a real-world example of using the Visitor Pattern. Then we're going to go into the code and we're going to see how we can refactor some code to use the Visitor Pattern and to make it so that code reduces some of the duplication that you would have to have if you didn't have the Visitor Pattern. Then finally, we will look at the UML of the Visitor Pattern and we'll see that it's really not that complicated even though there are quite a few parts to it.
Rules Pattern Hi there. My name is Steve Smith, and in this Pluralsight course we're going to examine a Design Pattern that isn't in the usual books, but which I have found to be particularly useful in a number of real-world scenarios. It involves identifying areas of frequent change in your application, typical with a lot of complexity, and replacing that complexity with a collection of objects that represent business rules. I call this the Rules Pattern. If you have any questions or feedback about this course, you'll find me online at Ardalis. com or on Twitter as @ardalis. There are some related courses on Pluralsight that you may find helpful in learning more about this pattern. In particular, there are two solid principles that heavily motivate the Rules Pattern. I'll be discussing them briefly here, but for more information on all of these principles, be sure to watch my SOLID Principles of Object Oriented Design course here on Pluralsight.
Specification Pattern Hi and welcome. This is Steve Smith. In this module we're going to examine the specification design pattern, which can be used to help reduce complexity in your business entities and data access logic, among other things. The pattern involves encapsulating rules for matching certain objects within their own named classes, and this can be especially helpful if you find that your UI code is cluttered with a lot of filtering logic that doesn't belong in that layer. Let's get started. We're going to cover the origin of the specification pattern first, and then we'll see some examples of real world scenarios in which it can be applied to improve application design. We'll look at the intent of the pattern and multiple ways in which it can be implemented, as well as some of the benefits that it provides. Then we'll look at a few common uses, as well as how the specification pattern works with another pattern, the repository. And finally, we'll take a look at some specific data access implementations using Entity Framework. The specification pattern was first published by Martin Fowler and Eric Evans as a whitepaper on Martin's website in 2002. You can find it there today. Eric incorporated the pattern into his approach to building software, described in his 2003 book, Domain-Drive Design. If you'd like to learn more about domain-driven design, or DDD, I recommend watching the DDD Fundamentals course here on Pluralsight, authored by Julie Lerman and me.