It’s one of the basics of any computer science curriculum: design patterns. Yet after leaving school the temptation is to reinvent the wheel yourself. That’s a shame, because correctly employing of design patterns yields a great deal of efficiency. That’s why at Itility, we keep each other on our toes when it comes to the power of design patterns.
What is a design pattern?
As a software engineer, the 23 design patterns of ‘the Gang of Four’ may well be displayed above your desk. In short, a design pattern is a proven recipe for solving a common problem. With you as the chef. And if you stick to the recipe, the basis is laid for a tasty dish with all the right flavors. Want to add some salt and pepper to the pattern? Go for it, albeit in moderation. It’s not a ready-made template in code, but a way to structure a software architecture, build a function, or a way of working.
Three types of design patterns
Once you know the design patterns you’ll see them everywhere. The original design patterns are divided into three main types: creational, structural and behavioral patterns. Creational patterns are all about creating objects. A structural pattern explicitly defines how multiple objects together form a larger structure, and a behavioral pattern streamlines processes when a certain type of behavior occurs. Later on new types of design patterns have seen the light, for example to cope with the complexities of concurrency or enterprise level applications. For each of the original types I have elaborated one pattern in a recognizable situation.
Choose a leased car with a creational pattern
When it is time to choose a new leased car, you’ll find you are working with a builder pattern. Here the pattern consists of four variables: you as a customer, the leasing company, the car builder and the florist. From the leasing company you order an Audi with a set of options: cruise control, alloy wheels and lane assist and the car should be red, of course. The company passes this on to Audi, which builds the car and delivers it in accordance with the specifications. As a surprise, the leasing company also orders a bouquet with a gold ribbon from the florist.
The pattern continues doing its job, even if you secretly dream about a dark grey Mercedes.
Builder Pattern diagram - Choosing a leased car
Charging phones with a structural pattern
You all know those moments when your phone is empty and you don’t have your charger with you. The moment you insert your colleague’s charger into your telephone, you’re dealing with an adapter pattern. The adapter converts between in the European 220 volt outlet that provides the electricity and the phone that expects a USB connection with 5 volts.
At home you use your wireless charger. This is a completely different input, but just as with the 220V charger, it converts the power in exactly the correct way. So after an hour you can return the charger to your colleague, with peace of mind.
Booking hotels with a behavioral pattern
Remember your last search for a hotel through the famous blue booking platform? Under your favorite hotel a red bar beckons: already booked four times this past hour. A clever design pattern is at work here: the observer pattern. Web site elements (observers) can register itself at the bookings’ site backend (subject). If something changes in the status of a room or a booking these elements get a notification from the subject and can choose to update their information.
The backend continuously knows if and who has booked a room somewhere. Not only for your room, but for all rooms, apartments and villas. As soon as someone else books and it’s the same room you’ve booked, the backend informs the counter in your browser that the fifth booking is confirmed. And then of course you can’t stay behind...
What design patterns bring us
Design patterns yield an interchangeable structure. But what are the benefits? Just a few of the things they do for us:
Reliable code
Everyone has their own way of working. But the goal is that as soon as someone checks in code, someone else can continue. Design patterns ensure reliability through their ‘proven’ design. And that applies not just to the code, but also to the way you create documentation and notes in your project.
New people quickly productive
If a project is growing rapidly in size, or someone changes jobs, you want productive newbies. Without design patterns, you would first have to explain to someone the whole coherence of the code, or the way of working. Can you imagine the months and frustrations flying by? If you use design patterns you can say: the updates of this dashboard use an ‘observer’ pattern. Now the newbie knows immediately how to use the code, or where to look up how the pattern works.
Easily share objects with other frameworks and languages
Python, C#, Vue, React, r: we use more and more languages and frameworks interchangeably. All these systems build and process objects in their own way. An adapter pattern helps you convert information from an object in Python to one in Vue for example, neutrally. Like translating the objects in Python to JSON and converting the JSON in Vue to a Vue object. Speaking of JSON, an adapter could also make it easy to keep legacy XML code compatible. You ‘just’ write an adapter for that.
New projects built faster
If people with the same skills work on many different projects, you’ll deliver faster. At Itility, the software developers are distributed across various customers. They keep each other fully updated on what they’re creating. By using design patterns in their projects, they exchange new functions and workflows efficiently if these also prove useful for their own project. That also means you don’t have to reinvent the wheel for structures that already exist in design patterns.
Better collaboration with other specialists
Okay, design patterns provide reliable code, and make newbies and new projects more productive. But does this also work outside the silo of software engineers? Absolutely! For example, our DevOps engineers work closely alongside the data scientists.
An example of our alerts: the software developer makes a ‘class’ available to the data scientist that implements the builder pattern. This way, the data scientist doesn’t have to worry about exactly how an alert is built up. He only has to focus on using the definition of the builder and add all the information he has regarding the alert. In the background the builder will take care of providing necessary extra information about the application name, links to documentation and network details.
Learning more about design patterns together
Thanks to design patterns there’s a lot to gain. A pattern can even be useful if you don’t do anything with code, but want to deliver projects in a uniform fashion. Curious about more basic principles about design patterns? Then download the slides of our training design patterns.
And would you like to receive more blogs about software development? Subscribe below.
