As a software developer, I’m always striving to improve the quality of my code.
Design patterns are one of many tools for good software design, therefore I’ve decided to create a blog post series covering the most important of these patterns.
Why Design Patterns?
Design patterns are solutions to common problems in software design.
These are a set of guidelines to help us organise our apps to be easier to understand, thus becoming more maintainable and flexible.
Be aware that knowing objected-oriented principles such as inheritance or polymorphism does not imply that you’re able to create good designs.
With this in mind, one should view patterns as higher-level concepts that have object-oriented principles as a foundation for creating flexible systems.
What I really like about design patterns is that they give you a shared vocabulary with other developers.
Therefore, your teammates will know immediately and precisely the design you’re describing.
With patterns, we have distilled years of experience and knowledge from other developers into a few concepts (OK, maybe not so few) that can be easily communicated with others.
Caveats
One should bear in mind that overuse of design patterns can lead to overengineered code.
As good software developers, we should acquire these patterns in our toolbox and have the ability to recognise when it’s appropriate to employ a particular pattern or not.
Here are some potential downsides of needlessly introducing design patterns in our models:
- higher complexity – our design’s complexity will increase as we use additional classes and objects.
- inefficiency – this is due to additional layers in our design.
- new bugs
- maintenance issues
I know it sounds obvious, but use patterns only if they are needed.
Reference Materials
The original book that documented design patterns was Design patterns: elements of reusable object-oriented software also known as the Gang of Four book, written by the Gang of Four (GoF) authors. They identified 23 object-oriented programming design patterns and split them into three categories: structural, creational and behavioural.
For the purpose of this series, I’ll be following the material in Professional Java EE Design Patterns. This is the book currently used in our Java Design Patterns Reading Group at my company, Avaloq.
Additionally, I’ll also study the material in the excellent Head First Design Patterns book for extra information.
The Plan
In the following weeks, I’ll cover the major design patterns, dedicating a blog post for each one. As I publish the articles, I’ll link to them from this page.
The posts will explain what’s the behaviour of a pattern, when it should be used and how it should be implemented in Java.
Design Patterns List (provisional)
- Structural Patterns
- Creational Patterns
- Behavioural Patterns
Next Steps
Go through the list of patterns above and try to recognise where it would be natural to apply them in your designs.
See how they are used “in the wild” in some open-source projects on GitHub.
Discuss your thoughts with your colleagues as part of a reading group.
With experience, you’ll develop a flair for when it’s appropriate to use a pattern.
Summary
To conclude, here are my three key points for you:
-
Design patterns give you a shared vocabulary with other developers.
-
Design patterns aren’t a magic bullet.
-
Go for the simplest solution that solves the problem and introduce patterns only when the need emerges.
