Designing object-oriented software is hard and designing reusable object-oriented software is even harder – Erich Gamma
When we’re talking about programming, there is no need to reinvent the wheel when we can follow well-known recipes. There’s where design patterns come in.
Design patterns are established and reusable solutions to address specific problems in a particular context. And the reality is that you probably used design patterns at some point without knowing it!
Using design patterns have several benefits, like:
- Facilitate communication among developers by providing a common language;
- Make it easier to reuse successful designs and avoid alternatives that diminish reusability;
- Facilitate design modifications;
- Improve design documentation; and
- Improve design understandability.
Design patterns can be creational, structural, or behavioral and can apply to classes or objects. Below you can find a list of several design patterns you can use when writing your code.
Yes, there are a lot of design patterns! Let’s see 2 of those patterns in more detail.
Singleton (creational pattern)
Singleton is one of the most common design patterns. The goal of Singleton is to ensure that only one instance of a class is created and provide a global access point to the object.
With Singleton, a new instance of a class will be created if none exists already. Otherwise, it returns the already created instance.
But why would you only want a single instance? Singletons are often part of other design patterns, like factory, builder, and prototype. Those patterns may need global configurations for the initialization, and a single instance must maintain these configurations at all costs.
Façade (structural)
The goal of Façade is to provide a unified interface to a set of interfaces in a subsystem. This design pattern defines a higher-level interface that makes the subsystem easier to use. In a nutshell, you’re wrapping up a complicated subsystem with a simpler interface.
Façade got its name as a metaphor for real-world architecture, where it imitates the visible front of a building. You only see what is visible at the front – the façade of the building – but you don’t get to see what’s inside.
This is just a starting point; you can explore all the patterns and see their implementation. So if you want to go deeper into design patterns, you can start by reading the book Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.
Is there any design pattern that you use regularly? Let us know