Design patterns for software were first made famous in the 1994 classic Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson, and Vlissides (aka Gang of Four). They took inspiration from a 1977 book, A Pattern Language: Towns, Buildings, Construction, by Christopher Alexander.
Alexander saw that there was a way to break more significant problems down into smaller repeatable patterns that solved specific problems.
“Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice”Christopher Alexander
A Pattern Language, 1977
Patterns start to show up over and over in software design as well. It is only the time-tested design patterns that transcend programming languages and their applications. But these patterns allow us to think about high-level concepts and improve software design and maintainability.
Maintaining Software to Survive Over Time
One of the benefits of using design patterns is its ability to create loosely coupled software. Making the opposite, tightly coupled software often leads to many of the bugs and extensibility issues we are forced to deal with, labeled “tech debt.” We all know that software can not last forever, so we need to plan for the enviable. The goal must be to create complex, highly scalable, more easily maintainable, and extendable software over time.
When considering software maintenance, we can organize them into four categories:
To fix existing bugs found in the software.
Modifications to support a changing environment.
When adding new features and improving existing functionality.
Changes to support future needs of the system.
When something is wrong with the software, we need to fix it. Corrective is the most common we all recognize. But the other three are also required for the software to survive over time. Creating tightly coupled systems causes this software growth to slow as it is often harder to adapt to changing requirements.
Why should we use design patterns?
Using design patterns shows many advantages—mainly creating reusable software.
Re-use design ideas from decades of programmers who have had similar issues.
Easy to discuss topics and use terminology that everyone understands.
Improve maintainability by using time-tested and production-hardened ideas.
Types of Patterns
A Design Pattern, as outlined in the Design Patterns book, can come in one of three forms.
Creational patterns abstract the creation of new objects in the software.
Design patterns that focus on how classes are constructed to build larger objects.
Behavioral patterns describe how objects interact and communicate with one another.
What Makes Up a Design Pattern
A descriptive name that describes the pattern and solution.
Describes which problems the pattern is best applied to.
Describes a general template on how a solution can solve the problem.
All architectural designs have pros and cons. This section describes the tradeoffs of using the design pattern.
- Abstract Factory
- Factory Method
- Chain of Responsibility
- Template Method
How to get started?
You can learn the design patterns and how they are implemented in your programming language. I have enjoyed the following books, but there are many other books on the subject: Design Patterns: Elements of Reusable Object-Oriented Software and Head First Design Patterns: Building Extensible and Maintainable Object-Oriented.
Once you are familiar with the design patterns, start to discuss and use them in design discussions with your team. Propose ways to improve your existing software system and learn what works for your software and situations.
Finally, never stop learning. This will not be a single overnight event but a series of improvements over time.
Design patterns are time-tested software design solutions that can help improve software maintainability. You can improve your software designs and communication by understanding and implementing software design patterns within your teams.
You are creating better software that is both an art and a science. Using design patterns will help you learn from common re-occurring problems many have had before you. This will help you build better software and improve your design skills. It’s a journey, in my opinion, well worth the effort.