Design patterns are a set of solutions for the most common problems in software design. The most commonly used patterns came from the book published in 1994. The question is, do we still need them in our modern software projects?
The short answer is: yes, we do. Wanna know the details? Read more.
What are they, why should we care?
Design patterns have been presented in the book called Design Patterns: Elements of Reusable Object-Oriented Software written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides – the famous Gang of Four (GoF).
You can think of it as the set of battle-tested, doable pieces you can use to improve the design of your code.
Well, it was in 1994, you might ask, didn’t the industry come up with more modern solutions? Are they still relevant?
Quick answer: yes. Especially when you’re at the beginning of your journey, design patterns are a good starting point.
Even if you won’t use them right away in your first projects, getting to know them will help you understand the existing solutions you’re using. Complex solutions are made of patterns. Think of frameworks and libraries you’re using.
If you’re more experienced but never had a chance to really analyze them, it’s even better. Getting a grasp on the most common patterns won’t take too long. You’ll get a chance to upgrade your developer toolbox and improve your problem-solving skills.
Besides, design patterns are a good communication tool. Why? Simply because the developers aren’t writing the code only for the machine itself.
In fact, the code is a way of communication with other developers. This is why having practical knowledge of design patterns will help you to set a common base in cooperation with other developers but also help you understand solutions you’re already using on a deeper level.
Patterns are everywhere
In the many places of the Internet, I saw the discussion about design patterns. Do we still need them? Are they still in use?
If you look at Google Trends, the design patterns search phrase trend is diminishing. Does it mean we don’t need them anymore? Well, I don’t think so.
In fact, they’re everywhere. Even if you’re not working on complex software projects on a daily basis or you’re not using anything more than your framework offers you. But for sure even your framework uses design patterns of some kind.
Categories of the patterns
GoF book presents the 3 categories of the design patterns:
- Creational
- Behavioral
- Structural
Although, over the years, one of the authors has admitted that this division is not really clear. The creational patterns are pretty obvious. Their goal is to create objects. But the border between behavioral and structural ones is fluid.
At the time of publication, authors simply didn’t know which patterns will be the most common.
The following patterns should be considered as the core ones. The kind of patterns you’ll probably need in most of the cases:
- Composite
- Strategy
- Decorator
- State
- Iterator
- Observer
- Mediator
- Facade
- Proxy
- Command
- Template Method
- Adapter
- Null Object, Value Object (both not included in the book)
As I mentioned before, patterns are largely used in the programming languages’ standard libraries. But some of the patterns were incorporated into the programming languages.
They became an integral part of the language hence not the patterns anymore. Think of Java’s Nullable which is the Null Object pattern implementation.
Whether you’re already familiar with the design patterns concept or not, I highly recommend you to watch this conference talk of Ralph Johnson, one of the GoF members.
He briefly described there all the learnings after over 20 years from the publication of the famous book:
How to deal with the patterns?
My approach is to read about the patterns, implement them along the way, read existing code, and start to recognize them (start with the frameworks and libraries you use).
The common mistake of developers is coming with a ready solution for the problem. Which means trying to fit the pattern you just learned to the.
The best you can do is to come up with the raw solution first, and then try to recognize the pattern use case if the implementation becoming painful. Classical red, green, refactor approach.
Design patterns in Kotlin
This blog post was an introduction to a series of posts about design patterns in the Kotlin language.
My goal was to present you few basic design patterns implemented using Kotlin language.
The code is available on GitHub.
The whole series will be using console testing output. If you want to set up the environment for yourself, please read this post.