Unless you are on the cutting edge of computer science, most of the software you write will be more focused on user experience and maintainability than on any particular advanced programming language. As you write more and more of this type of software, you will see a lot of patterns emerge, especially if you focus on readability and maintainability, as most of us should. However, we don't have to come up with all of these patterns on our own; people have been programming and coming up with patterns for years that transfer really well from language to language.
We call these patterns, design patterns. Design patterns is a massive topic with countless books, tutorials, and other resources. We spend our entire careers practicing, shaping, and perfecting the use of these patterns in practical ways. We give each pattern a name so that we can have smoother conversations with fellow programmers and also organize them better in our own minds.
In this chapter, we will take a look at some of the most common design patterns, especially the ones important to understand Apple's frameworks. You will have a much easier time understanding and making use of that code when you begin to recognize patterns while using other people's code. It will also help you write better code yourself. We will focus on the high level ideas behind each pattern and then how to implement them in Swift. We will then go past the classic design patterns and look at some advanced features of Swift that allow us to write particularly clean code.
To do all that, we will cover the following topics in this chapter:
- What is a design pattern?
- The behavioral patterns
- The structural patterns
- The creational patterns
- Using associated values effectively
- Extending system types to reduce code
- The lazy properties
Let's delve a little deeper into what a design pattern is before we dive into the specific patterns. As you may have begun to understand, there are unlimited ways to write a program that does even a simple thing. A design pattern is a solution to solve a recurrent and common problem. These problems are often so ubiquitous, that even if you don't use a pattern deliberately, you will almost certainly be using one or more patterns inadvertently; especially, if you are using third-party code.
To better evaluate the use of design patterns, we will look at three high-level measurements: coupling, cohesion, and complexity.
Coupling is the degree to which individual code components depend on other components. We want to reduce the coupling in our code so that all our code components operate as independently as possible. We want to be able to look at them and understand each component on its own without needing a full understanding of the entire system. Low coupling also allows us to make changes to one component without drastically affecting the rest of the code.
Cohesion is a reference to how well different code components fit together. We want code components that can operate independently, but they should still fit together with other components in a cohesive and understandable way. This means that to have low coupling and high cohesion, we want code components that are designed to have a single purpose and a small interface to the rest of our code. This applies to every level of our code, from how the different sections of our app fit together, down to how functions interact with each other.
Both of these measurements have a high impact on our final measurement: complexity. Complexity is basically just how difficult it is to understand the code, especially when it comes to practical things like adding new features or fixing bugs. By having low coupling and high cohesion, we will generally be writing much less complex code. However, taken to their extremes, these principles can sometimes actually cause greater complexity. Sometimes the simplest solution is the quickest and most effective one because we don't want to get bogged down into architecting the perfect solution when we can implement a near perfect solution ten times faster. Most of us cannot afford to code on an unlimited budget.
Instead of having a single giant list, design patterns are usually organized according to how they are used into three main categories: behavioral, structural, and creational.