Fiodar Sazanavets - The easiest way to learn design patterns: With C# code samples using .NET 6 templates

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 wont 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 youll 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, lets go through a quick overview of what they 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.

Lets 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 doesnt prescribe is what specific behavior should the implementation perform or what data type(s) should it return, if any. Its up to us to decide.

Some design patterns dont 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.

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.

Lets 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 doesnt 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. Lets examine why that is.

Many developers, especially the ones who dont 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.