This is an introduction from a book The easiest way to learn design patterns. The book is available in digital format at LeanPub and as either Kindle-specific format or in print from Amazon.

Design patterns are something that you will need to get familiar with as a programmer who works with object oriented languages. And this is primarily because they represent well-defined solutions to common software development problems. So, instead of thinking through all the details of your solution, you can simply check if any of the existing design patterns can be used. You won’t have to reinvent the wheel.

As a software developer, you would be familiar with reusable software components, such as methods, functions, public classes, libraries, etc. Well, you can think of design patterns as reusable solutions to common software problems. If you are familiar with which design patterns can solve a specific type of a problem, you will no longer have to come up with a bespoke solution, which could have taken you a significant amount of time to design and implement. All you’ll have to do is just pick the mostly suitable design pattern and apply it in a specific way to solve this specific problem. The solution is already there. The time taken to implement it would not be much greater than the time it takes you to type the code in.
If you are new to design patterns, let’s go through a quick overview of what they are.

What design patterns are

Design patterns are prescribed ways of implementing solutions to common problems. While every specific implementation of them will be bespoke and only relevant to a specific codebase, they still determine how your code should be structured. A design pattern would tell you how different object types in your code should interact with one another. Specific objects would have specific roles, which are prescribed by a specific design pattern. But a specific implementation of those objects would still be relevant only to a specific problem.

If you will, you can compare the concept of design patterns with Agile principles. For example, if you follow Scrum, you would go through all of the relevant ceremonies (daily standups, sprint reviews, etc.). You would have specific roles (Scrum master, product owner and Scrum team members). You would work in sprints of a specific length. But the problems that you will be solving during your sprints will be very specific to your organization. The actual implementation of Scrum methodology will be bespoke.

Design patterns have been used in object oriented programming for some time. But in 1994, they have been officially classified and described in a book called Design Patterns: Elements of Reusable Object-Oriented Software, which was written by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, who are collectively known as The Gang of Four.

So, in a nutshell, each design pattern prescribes how the objects in your code should be structured and how they should behave. For solutions where multiple objects are involved, it prescribes the role for each object.

Let’s have a look at a design pattern called Strategy as our example. This pattern is commonly used to make your code easily maintainable and testable in situations where you have complex conditional logic. In this design pattern, you have an class with the role of Strategy. This class stores an interface, which has a role of *Context*. There are several classes that implement this interface, each performing a specific behavior. Then, all you do inside your conditional logic is assign a specific Context implementation to the Strategy. And then, once all conditions have been examined, you just execute some method on the Context object which Strategy class encapsulates. This will execute the behavior that was specific to a particular condition, as a specific implementation of Context was assigned to Strategy when a specific condition was hit.

So, the design patterns prescribes roles to objects and how these objects should interact with one another. We have one object with the role of Strategy and several implementations of an object with the role of Context. But what the design pattern doesn’t prescribe is what specific behavior should the implementation perform or what data type(s) should it return, if any. It’s up to us to decide.
Some design patterns don’t even involve multiple objects with different roles. Singleton and Prototype patterns, for example prescribe how to apply internal logic to an object of and what public members should this object have for other objects to access.

So, why would you use design patterns? Why just not provide a bespoke solution to every problem you face? Well, there are some good reasons why design patterns are better. But the reasons why you would want to learn them go beyond the fact that design patterns merely provide a better solution.

Why would you want to learn design patterns

Design patterns will indeed make you more effective at solving problems. When you have used them for a while, you will intuitively know where to apply them. So, you will not have to spend much time thinking of the solution. You will be able to apply one right away.

Not only will you be able to solve the problem quicker, but your code will be cleaner. It will be more readable, easier to test, and easier to maintain.

Let’s go back to our example of Strategy pattern. You can, of course, just use a complex conditional logic in a single method of your code. But then imagine how hard it might be to test the logic. Also, if the logic is complex, it might not necessarily be the most readable code.

When Strategy pattern is implemented, it solves the problem.But beyond that, it makes your code clean. The original method that contains the conditional logic only selects which Strategy to implement. It doesn’t do anything beyond that. Easy to read. Easy to test. Each Strategy implementation only contains an atomic piece of logic that is responsible for only one action. Easy to read. Easy to test.

But the benefits of knowing design patterns go beyond them being good solutions to common problems. Many reputable organizations ask questions about them during job interviews. The major IT giants almost certainly do. So, not knowing design patterns might prevent you from getting a job in the company of your dreams.

The main problem with design patterns is that they are not necessarily easy to learn. Let’s examine why that is.

Why design patterns are hard to learn

Many developers, especially the ones who don’t have a lot of software-building experience, struggle with design patterns. But if you do struggle with them, it may prevent you from getting a programming job at a reputable organization. After all, recruiting managers often ask questions about design patterns. Otherwise, not knowing design patterns will make you less effective as a software developer, which will slow down your career progress.

The main reason why design patterns are so hard to learn is because of the way they are normally taught. Usually, if you pick pretty much any book on design patterns or open pretty much any online article about them, it would provide a collection of design patterns that you would need to go through. You would then have to go through each of them, try your best to understand the principles behind it and only then try to figure out how to apply it in a real-life situation.

It’s a tedious process that doesn’t always bring about the right results. It’s not uncommon for software developers to memorize just a handful of design patterns that they have been using in their own projects. The remaining ones have been forgotten as soon as they’ve been learned. And it’s hard to figure out which design pattern applies in which situation if you only remember a handful of them.

The goal of this book

This book provides a different approach. It uses a methodology that makes it easy to learn design patterns. So, you no longer have to brute-force your way through them. The process of effective learning is not about memorization. It’s about associations. You learn new things easily when you can clearly see how new facts relate to your existing knowledge. And this is precisely the method that this book is built around.

You won’t have to brute-force your way into design patterns. In fact, you won’t even start with the design patterns. First, we will go through a list of common problems that software developers are required to solve. Those are the things that every software developer can associate with. Even if you haven’t faced a particular type of a problem yet, you will still be able to easily understand its description. For each of these problems, we will go through the design patterns that can solve it. And for each one of them, you will go through its core principle and the description of how it can solve this type of a problem. Only then you will be invited to examine this particular design pattern in detail, so you can understand how to implement it in your own code.

This structure of the book also makes it valuable as a reference book. Even when you don’t know or don’t remember design patterns, looking them up becomes easy. What you need to find is a description of the type of a problem you are trying to solve. And then you will be able to follow it to find the actual design patterns that you can apply to solve it.

Therefore this book is not only an effective learning tool. It’s also a reference book that’s incredibly easy to navigate. It’s been structured in such a way that you’ll be able to find the right answer in seconds.
One important thing to note is that this book doesn’t aim to cover absolutely all design patterns that exist out there. It focuses on the classic design patterns that were outlined by The Gang of Four. So some of the design patterns that you have heard of might be missing.

However, these classic design patterns formed the foundation for all design patterns that came after. Therefore, if you get familiar with them, you will have no trouble learning any newer patterns.

The structure of this book

This book consists of three parts. It has been structured to facilitate easy learning of design patterns for those who aren’t familiar with them.

Part 1: SOLID principles and why they are important

SOLID principles are the most fundamental rules of clean code in object-oriented programming. And all design patterns depend on these principles. This is why, in order to be able to understand design patterns, you need to be familiar with SOLID principles. This is why this is the very first thing that you will learn in this book.

Part 2: The problems that design patterns are intended to solve

This part lists various problem types that software developers commonly face. And for each of these problems, it provides a list of design patterns that can solve it.

This part of the book doesn’t provide an in-depth description of each of the patterns. It merely provides a brief overview of what each design pattern does and how it can solve a specific type of a problem.
This part of the book has been structured in such a way to ensure that those developers who aren’t yet familiar with design patterns can easily look them up and be able to quickly find the most suitable design pattern for a specific type of problem they are facing.

Part 3: Design patterns demonstrated in C#

The final part of the book breaks down each of the design patterns in depth. It uses C# code samples to demonstrate how you can implement each of the patterns in your own code.

About the author

Fiodar Sazanavets is an experienced lead software engineer whose main area of expertise is Microsoft stack, which includes ASP.NET (Framework and Core), SQL Server, Azure, and various front-end technologies. Fiodar is familiar with industry-wide best practices, such as SOLID principles, software design patterns, automation testing principles (BDD and TDD) and microservices architecture.

Fiodar has built his software engineering experience while working in a variety of industries, including water engineering, financial, retail, railway and defense. He has played a leading role in various projects and, as well as writing software, he gained substantial experience in architecture and design.
Fiodar is an author of a number of technical books and online courses. He regularly writes about software development on his personal website, https://scientificprogrammer.net. He is also available to book for personal mentoring sessions via https://mentorcruise.com/mentor/fiodarsazanavets.

Getting in touch with the author

If you want to get in touch with me regarding the content of the book, you can contact me via either Twitter or LinkedIn. Perhaps, there is additional content that you want to have included in the next edition of the book. Or maybe you found some errors in the current edition. Any feedback is welcome. And this is how you can get in touch:

Twitter: https://twitter.com/FSazanavets

LinkedIn: https://www.linkedin.com/in/fiodar-sazanavets/

Helping to spread the word

If you found this book useful, please write a review about it. This will help the author and will help the algorithms to show this book to more people who might need help with learning design patterns.

And, of course, if you liked this book, spread the word. Let your friends know about it. This way, you will help more people to become better software developers.