“What is a design pattern?”. A design pattern is a kind of template that describes how to solve a problem, it can be used in many different situations and is used to solve common problems that occur in software design.
I will attempt to put that definition into some context. Imagine you are a kitchen designer and you design kitchens for restaurants. Years of experience may have taught you that in a professional kitchen, certain appliances are best positioned in certain places, pots and pans near stoves and ovens, or chopping boards near the sink. Every kitchen you design, you apply your theory as your experience shows it makes a kitchen more productive, things are easier to find and are within easy reach. You could say this is a design pattern, it solves a common problem, it is not physical, it is not a concrete thing, it is a template that describes a solution to a problem.
In the weeks ahead we will go through some of the main design patterns, what they are when they can be used and what benefit they provide, but first, let us go through some of the benefits that design patterns provide.
Speeding up the development process and reduce bugs
The use of design patterns can help to speed up the development process by aiding the development of testable code. The testable code allows automated tests to run that are able to check that aspects of the system are functioning as they should be. Tests also help to prevent the injection of bugs when changes are made to the system, as the tests be can run to confirm that changes have not affected other parts of the system. It is common knowledge that most bugs that appear in a system are generated as a result of changes made to an existing system, a change is made and tested individually, however without testing the whole system manually you have no idea if that change has broken something else. Testing (or unit tests) allow developers to quickly test most if not all of the system before deploying a change, catching bugs before they get to the end user.
Improved code readability
When design patterns are used, it makes the code of a system easier to understand for other developers, especially if they too have a good knowledge of design patterns. It becomes clear to others reading the code which patterns are being used, and from that, they understand how to interact with the system when making changes.
Forces you to think ahead
The use of design patterns forces you as a software engineer to think ahead, it forces you to think about future changes and how easy the system will be to maintain and expand upon in future. This encourages you to consider issues that may not normally become visible until later in the development process.
More maintainable and expandable code
The application of design patterns to a system help to make a system more maintainable, and as a result of thinking ahead, the system can be more expandable. Different aspects of the system are loosely coupled, which tries to limit the amount of code that needs changing when a change is made. The fact that different parts of the system are not dependant on other parts of the system, allows sections of code to be easily re-written or replaced as long as it follows the same contracts. A popular phrase used by developers and engineers is “develop to interfaces”, and this is one of the principles regularly applied software design to reduce dependencies in a system.
What if I don’t apply design patterns?
For a start, the world will not end. However, design patterns exist for a reason, they exist because developers regularly come across the same type of problem over and over again, how do you make a system testable, how to you make a system easy to understand, how to you make a system easy to be maintained and expanded upon. How do you make it easy for parts of a system to be replaced, or how do you make it easy for a system to switch from an SQL data source to a NOSQL data source with little change to the business layer? Design patterns go some way to help to answer these questions, and some questions you’ve probably not asked yet, questions that may only arise at a later date.
In the next part of this series we will take about the Strategy Pattern.