This section tells you a few things you need to know before you get started, such as what you’ll need for hardware and software, where to find the project files for this book, and more.
This is a high-level introduction to what design patterns are, why they’re important, and how they will help you.
You’ll also learn how to read and use class diagrams in this section. This will make it much easier for you to learn design patterns, so it’s important to go over this first to get the most out of the book.
Design patterns aren’t concrete implementations, but rather, serve as starting points for writing code. They describe generic solutions to problems that many experienced developers have encountered many times before. What does this mean exactly...? Learn this and more in this chapter.
You may have heard of Unified Modeling Language, which is a standard language for creating class diagrams, architectural drawings and other system illustrations. A complete discussion of UML is beyond the scope of this book, but you won't need to understand a lot of UML in your day-to-day iOS development. Instead, you'll learn a subset of UML in this chapter that's useful for creating class diagrams and describing design patterns.
This section covers essential iOS design patterns. These patterns are frequently used throughout iOS development, and every iOS developer should understand these well.
These patterns work well in combinations, so all of the chapters in this section walk you through building a single tutorial project from the ground up.
The model-view-controller (MVC) pattern separates objects into three distinct types: models, views and controllers! MVC is very common in iOS programming, because it's the design pattern that Apple chose to adopt heavily in UIKit. In this chapter you’ll implement the MVC pattern as you start to build out the first app in this book: RabbleWabble.
The delegation pattern enables an object to use another “helper” object to provide data or perform a task rather than the task itself. By relying on a delegate protocol instead of a concrete object, the implementation is much more flexible: any object that implements the protocol can be used as the delegate! You'll continue the RabbleWabble app from the previous chapter, and add a menu controller to select the group of questions.
The strategy pattern defines a family of interchangeable objects that can be set or switched at runtime: the object using a strategy, the strategy protocol, and the set of strategies. You continue to build out RabbleWabble and learn how these three components work together in the strategy pattern.
The singleton pattern restricts a class to only one instance. Every reference to the class refers to the same underlying instance. It is extremely common in iOS app development, because Apple makes extensive use of it.
The memento pattern allows an object to be saved and restored. you can use this pattern to implement a save game system, where the originator is the game state (such as level, health, number of lives, etc), the memento is saved data, and the caretaker is the gaming system. You can also persist an array of mementos, representing a stack of previous states. You can use this to implement features such as undo/redo stacks in IDEs or graphics software.
The observer pattern lets one object observe changes on another object. You’ll learn two different ways to implement the observer pattern in this chapter: using key value observation (KVO), and using an `Observable` wrapper.
The builder pattern allows the creation of complex objects step-by-step, instead of all at once, via an initializer. For example, you can use this pattern to implement a “hamburger builder”. The product could be a “hamburger” model, which has inputs such as meat selection, toppings and sauces. The director could be an “employee” object, which knows how to build hamburgers, or it could be a view controller that accepts inputs from the user.
This section covers design patterns that are also common, but are used less frequently than the fundamental design patterns in Section II.
Many of these patterns work well together, but not all. You’ll create two projects in this section as you explore these intermediate patterns.
Use this pattern when you need to transform models into another representation for a view. This pattern compliments MVC especially well. You’ll embark on a new project — CoffeeQuest — to help you find the best coffee shops around.
The factory pattern provides a way to create objects without exposing creation logic. Technically, there are multiple "flavors" of this pattern, including a simple factory, abstract factory and others. However, each of these share a common goal: to isolate object creation logic within its own construct.
Classes, modules, and functions can’t always be modified, especially if they’re from a third-party library. Sometimes you have to adapt instead! You can create an adapter either by extending an existing class, or creating a new adapter class. This chapter will show you how to do both.
The iterator pattern provides a standard way to loop through a collection. Use the iterator pattern when you have a class or struct that holds a group of ordered objects, and you want to make it iterable using a “for in” loop.
Methods are merely functions that reside in a class. In this chapter, you’ll take a closer look at methods and see how to add methods onto classes that were created by someone else. You’ll also start in on a new project with this chapter: a drawing app named MirrorPad.
The state pattern is a behavioral pattern that allows an object to change its behavior at runtime. It does so by changing its current state. "State" here means the set of data that describes how a given object should behave at a given time.
The multicast delegate pattern is a behavioral pattern that’s a variation on the delegate pattern. It allows you to create one-to-many delegate relationships, instead of one-to-one relationships in a simple delegate.
The facade pattern is a structural pattern that provides a simple interface to a complex system. Use this pattern whenever you have a system made up of multiple components and want to provide a simple way for users to perform complex tasks.
This section covers design patterns that are very useful but only in rare or specific circumstances. These patterns may be exactly what you need for a particular case, but they may not be useful on every project. However, it’s best to be aware of them as you’ll undoubtedly run across them at some point in your development career.
This creational design pattern minimizes memory usage and processing. It also provides objects that all share the same underlying data, thus saving memory. Learn about flyweight objects and static methods to return them.
This is a behavioral design pattern that encapsulates how objects, called colleagues for this pattern, communicate with one another. This pattern is useful to separate interactions between colleagues into an object, the mediator. Learn how to use it when you need one or more colleagues to act upon events initiated by another colleague.
This is a structural pattern that groups a set of objects into a tree so that they may be manipulated as though they were one object. If your app's class hierarchy forms a branching pattern, trying to create two types of classes for branches and nodes can make it difficult for those classes to communicate. Learn how to reduce complexity and solve this problem with this pattern.
This is a behavioral pattern that encapsulates information to perform an action into a command object. Learn how you can model the concept of executing an action and to use this pattern whenever you want to create actions that can be executed on different receivers.
This is a behavioral design pattern that allows an event to be processed by one of many handlers. See how to use this pattern whenever you have a group of related objects that handle similar events but vary based on event type, attributes or something else related to the event.
The coordinator pattern is a structural design pattern for organizing flow logic between view controllers. This pattern can be adopted for only part of an app, or it can be used as an “architectural pattern” to define the structure of an entire app. You’ll see both of these at work in this chapter.
