Software Design Patterns can make the live of a software engineer much easier. They help solve problems that have been encountered numerous times and have been solved.
In this article I’ll show you the ones I use or like the most and how to apply them.
Why use Software Design Patterns
As mentioned at the beginning, they make your life easy, because they solve often encountered problems in an easy way.
It’s like using the formula for the general quadratic equation to solve a quadratic equation. Easy.
Additionally they help communicate faster. Instead of explaining how to solve a problem, you can reference a pattern like Singleton, and everyone is up to date. With one word, instead of 3-5 sentences.
Software Design patterns also make your code more reusable, maintainable and flexible to changes, which is a huge bonus :D.
There is a good book about almost all Software Design Patterns by the GoF, there is another one by Craig Larman that discusses using them in an iterative software engineering cycle.
Strategy Pattern
It may not be the most important of the Software Design Patterns, but it is definitely one of my favourites.
The strategy pattern allows grouping related algorithms under the same abstraction.
Let’s say you’re developing a LevelExperienceAPI for an RPG like Final Fantasy VII. Usually you would convert EXP into a LVL and vice versa. The API will be used by other developers.
But there are different ways to convert EXPs to LVL’s. For example linear progression, where each 1000EXP you gain a Level. Or you could level up with a sigmoid function, which means the first couple of levels will go faster than the last couple of levels, which is usually the case (e.g. LVL 2 -> 200EXP, LVL 67 -> 98770 EXP).
Instead of choosing one method to calculate the EXP, you can use the Strategy Pattern.
You’ll need an interface (or abstract class) IEXPConversionStrategy with a method to convert EXP into LVL and another method to convert LVL into EXP.
Then you can create an implementation of the interface for each different strategy and the developers using it could pass the appropriate strategy to the constructor. They could even create a custom one and pass that one.
The context would be the API and the ConcreteStrategies would be the ConversionStrategies.
Observer/Pub-Sub Pattern
This design pattern is handy to manage one-to-many dependencies between objects and maintaining a persistent state.
Usually it consists of an observer that subscribes to the subject object which publishes updates.
A real life example would be a newsletter. If you subscribe to my newsletter you become the observer and every time I publish a new issue, you get notified.
Btw, pls sub to my newsletter. thx.
Let’s say you’re making a clock. Basically it consists of minutes and seconds. The class Clocktick has a method tickSecond and tickMinute (but no TikTok).
It also has two list of observers, minuteobservers and secondobservers. Everytime the tickSecond is called, it notifies all it’s secondobservers and the same for minutes.
You can now create a command line interface, a web gui, a Java FX gui or whatever you like (or all at the same time) and add the corresponding text-component to the list of observers.
Now every time the clock ticks, the GUI elements will call their update method, which could change the text (for example).
Of course GUI’s aren’t the only use case for this pattern. If you have a light switch with multiple lights connected to it, you could represent it in software with the observer pattern for a smart home system.
Singleton Pattern
If any pattern is known under the common Software Design Patterns it will be the singleton.
A singleton is an object, of which there exists just one instance of. It can be combined with other patterns such as Factory Pattern, Builder and more.
If you create a Game with different courses, player etc… You’ll need a GameManager, which can handle communication between the objects (as a Mediator) and store crucial data (like who is currently winning).
Usually these GameManagers are implemented as singletons. This allows every Object to call functions/methods from the GameManager without creating a new instance. But it can become tempting to create a know it all instance and use that for everything, which will result in cluttered and messy Software Design.
The world of Software Design Patterns
There’s more to Software Design Patterns than this article can cover, this is why I would like to recommend some books I read about the topic and I found interesting:
Applying UML and Patterns by Craig Larman.
PS: If you purchase them via my link, I’ll get a small commission which supports this blog 🙂
