Introduction to Design Patterns
Explore the concept of design patterns and their role in solving common programming issues. Understand misconceptions about design patterns and see how they apply not only to Kotlin but across many domains. Learn the design process through real-life examples and develop a foundation for using design patterns effectively.
We'll cover the following...
Now that we are a bit more familiar with basic Kotlin syntax, we can move on to discussing what design patterns are all about.
What are design patterns?
There are different misconceptions surrounding design patterns. In general, these misconceptions include:
- Design patterns are just missing language features.
- Design patterns are not necessary in a dynamic language.
- Design patterns are only relevant to object-oriented languages.
- Design patterns are only used in enterprises.
Actually, design patterns are just a proven way to solve a common problem. As a concept, they are not limited to a specific programming language (Java), nor to a family of languages (the C family, for example), nor are they limited to programming in general. We may have even heard of design patterns in software architecture, which discuss how different systems can efficiently communicate with each other. There are service-oriented architectural patterns, which we know as Service-Oriented Architecture (SOA), and microservice design patterns that evolved from SOA and emerged over the past few years. The future will, for sure, bring us even more design pattern families.
Even in the physical world, outside of software development, we’re surrounded by design patterns and commonly accepted solutions to a particular problem. Let’s look at an example.
Design patterns in real life
Have you ridden an elevator lately? Was there a mirror on the wall of the elevator? Why is that? How did you feel when you last rode an elevator that had no mirror and no glass walls?
The main reason we commonly have mirrors in our elevators is to solve a frequent problem—riding in an elevator is boring. We could put in a picture. But a picture would also get boring after a while, if you rode the same elevator at least twice a day. Cheap, but not much of an improvement.
We could put in a TV screen, as some do. But it makes the elevator more expensive. And it also requires a lot of maintenance. We need to put some content on the screen to make it not too repetitive. So, either there’s a person whose responsibility is to renew the content once in a while or a third-party company that does it for us. We’ll also have to handle different problems that may occur with screen hardware and the software behind it. Seeing the blue screen of death is amusing, of course, but only mildly.
Some architects even go for putting elevator shafts on the building exterior and making part of the walls transparent. This may provide some exciting views. But this solution also requires maintenance (dirty windows don’t make for the best view) and a lot of architectural planning.
So, we put in a mirror. We get to watch an attractive person even if we ride alone. Some studies indicate that we find ourselves more attractive than we are, anyway. Maybe we get a chance to review our appearance one last time before that important meeting. Mirrors visually expand the visual space and make the entire trip less claustrophobic or less awkward if it’s the start of a day and the elevator is really crowded.
Design process
Let’s try and understand what we did just now. We didn’t invent mirrors in elevators. We’ve seen them thousands of times. But we formalized the problem (riding in an elevator is boring) and discussed alternative solutions (TV screens and glass walls) and the benefits of the commonly used solution (which solves the problem and is easy to implement). That’s what design patterns are all about.
The basic steps of the design process are as follows:
- Define exactly what the current problem is.
- Consider different alternatives based on the pros and cons.
- Choose the solution that solves the problem while best fitting our specific constraints.
