1. What are Design Patterns?

Written by Joshua Greene

“Extra, extra! Read all about it!”

“Feared by newcomers. Loved by architects. Read the inside story about design patterns. The truth may surprise you!”

Did you know design patterns can make you a better developer? “Of course,” you say — you are reading this book, after all!

Did you know design patterns can help you make more money? It’s true. You can save time, work less and ultimately create more great things by using design patterns correctly.

And did you know design patterns can help you fight vampires? OK, maybe not — design patterns aren’t silver bullets, after all.

However, design patterns are incredibly useful, no matter what language or platform you develop for, and every developer should absolutely know about them. They should also know how and when to apply them. That’s what you’re going to learn in this book!

A real-world example

The introduction told you that design patterns are reusable, template solutions to common development problems. Design patterns aren’t concrete implementations, but rather, serve as starting points for writing code. They describe generic solutions to problems that experienced developers have encountered many times before.

What does this mean exactly…? Consider this non-development, real-world scenario:

You’re the proud owner of a gardening company, and your business is really, er, blooming. You’ve only done a few small projects up to now - a tree planted here and a few flowers there. However, you just landed a big client who wants several dozen trees and flowers planted on their property.

Your standard procedure has been for your employees to carry each flower or tree sapling into place individually. Once each has been temporarily placed, your customer inspects and approves the arrangement before you plant everything in the ground.

You’re worried it’s going to take forever to carry each flower and tree into place for this large project. And you even need a few people to carry some of the bigger trees. While you could hire lots of temporary employees, you wouldn’t make a profit on the job. There’s got to be a better way!

You decide to ask other gardeners what they do, and you find out they use wheelbarrows and carts. What a great idea! You tell your employees to use a cart to move multiple flowers at the same time and a wheelbarrow to move the heavy trees. In the meantime, you use a lounge chair chair to watch your workers go to it… isn’t management great?

So now you know all about design patterns! Wait, you need more details? Okay, let’s break it down…

Example explanation

The “design pattern” here is the use of wheelbarrows and carts. These are common, best practice tools in gardening. Similarly, software design patterns form a set of best practices in development. You could have chosen not to use wheelbarrows and carts, but akin to avoiding software design patterns, you assume more risk by making the project more time- and labor-intensive.

Back to the point of “asking other gardeners what they do.” Most design patterns have been around for a long time — having started life in the 1970s and 1980s — and they continue to work well to this day.

This longevity is partly due to the fact their use has been validated in many projects over the decades, but it’s also because they aren’t concrete solutions.

In the gardening scenario, you decided that carts will be used to move flowers and wheelbarrows will be used to move trees. These are implementation details: you could have used carts to move both flowers and trees, only used wheelbarrows, or any other combination that made the job easier.

Design patterns are generic, go-to solutions for solving common problems, like using wheelbarrows and carts. They are starting points for concrete implementations, like using carts for flowers and wheelbarrows for trees.

Make sense? Great! It’s now time to leave the garden behind and head back to the world of software design patterns.

Types of design patterns

There are three main types of design patterns:

1. Structural design pattern: Describes how objects are composed and combined to form larger structures. Examples of structural design patterns include Model-View-Controller (MVC), Model-View-ViewModel (MVVM) and Facade.

2. Behavioral design pattern: Describes how objects communicate with each other. Examples of behavioral design patterns are Delegation, Strategy and Observer.

3. Creational design pattern: Describes how to create or instantiate objects. Examples of creational patterns are Builder, Singleton and Prototype.

You may be wondering if knowing a design pattern’s type really matters. Well, yes…and no.

It’s not useful to memorize all patterns by type. Most developers don’t do this. However, if you’re not sure whether a particular pattern will work, it’s sometimes useful to consider other patterns of the same type. You just might find one that works better for your particular problem.

Note: There’s an ongoing debate on whether some patterns, including MVVM and MVC, are actually architectural patterns, which span an entire app or subsystem architecture. Hence, they are broader in scope than design patterns, which only span components or pieces of an app. Architectural patterns can even use or encompass several design patterns.

For the purposes of this book, a comprehensive discussion of architectural patterns is out of scope. We’ve chosen to label MVVM and MVC as structural design patterns because they can be used alongside other design patterns in a component fashion. They are also very commonly used in iOS projects, and we wanted to ensure we covered them.

If someone says these are actually architectural patterns, we don’t necessarily disagree, as they can also be used that way.

If you’d like to learn more about iOS architectural patterns, check out Advanced iOS App Architecture (http://bit.ly/ios-app-arch).

Criticisms of design patterns

As indicated earlier, “there are no silver bullets in software development,” and design patterns are no exception to this. This means that simply knowing and employing design patterns will not guarantee you will create a well-architected piece of software. There are dozens of design patterns, so knowing when and how to employ each one is important.

What are some common criticisms of design patterns?

If you overuse design patterns, your project can become overly complex.

You need to be careful about overusing any tool, including design patterns. You can minimize this issue by clearly and correctly defining the problem to be solved before adding a design pattern to your project.

Many design patterns are made redundant by modern programming languages.

It’s true that modern programming languages like Swift make some design patterns irrelevant or trivial to implement. However, just because some patterns are provided via a programming language doesn’t mean all patterns will be.

Design patterns are a lazy substitute for learning object-oriented principles.

Why not learn both? A strong understanding of object-oriented principles will certainly help you in your development.

However, if you already know a design pattern works well for a particular problem, why should you reinvent the solution from scratch?

But, but…check out this thread on Twitter, which definitely shows that design patterns are worthless!

Regardless of the particular criticism, design patterns have been around for a long time, and they’ve been used in many apps. So at some point, you’re going to encounter them.

We think it’s best to have an understanding of what they are before you run into them, instead of trying to wing it on the fly, which in our experience is usually late on a Sunday night, the day before the release deadline, right after discovering a critical bug.

Benefits of design patterns

We’ve mentioned many benefits of design patterns already, but there are a few more.

Design patterns create a common language.

Instead of describing a particular solution in detail, you can simply state which design pattern you think would work best. This streamlines communication between developers.

Design patterns fast-track developer onboarding.

It’s much easier to onboard a new developer on a project that uses design patterns, than on a project with completely custom logic.

Design patterns make you a better person.

Well, this one may still be up for debate. But some degree of self-improvement is never wasted! However, there is a grain of truth to this, as the next developer to maintain your project will certainly think you’re a better person for having left them a nice, design-pattern-filled project instead of a spaghetti-coded mess!

Knowing design patterns allow you to spot similarities between code.

Once you know and understand different design patterns, you begin to notice their use in code. This gives you a leg up as you are at least a little familiar with how to use that code. For example, iOS and Mac programming makes heavy use of the Delegation pattern. You would spot this pattern easily if you ever moved to another platform that also uses Delegation and instantly be familiar with how the code is organized.

Key points

In this chapter, you learned what design patterns are and why you should care about them. Here are the key points to remember:

• Design patterns aren’t concrete implementations, but rather, they are a starting point for writing code.

• Design patterns collectively form a set of best practices to help you write more understandable and easier-to-maintain code.

• There are three main types of design patterns: structural, behavioral and creational.

• There are both criticisms and benefits of design patterns. Ultimately, they are commonplace in software development, and you’re likely to encounter them. Therefore, having a good grasp of them is important.