The first behavioral pattern we will discuss is called the iterator pattern. We are starting with this one because we have actually already made use of this pattern in Chapter 6, Make Swift Work For You – Protocols and Generics. The idea of the iterator pattern is to provide a way to step through the contents of a container independent of the way the elements are represented inside the container.

As we saw, Swift provides us with the basics of this pattern with the GeneratorType and SequenceType protocols. It even implements those protocols for its array and dictionary containers. Even though we don't know how the elements are stored within an array or dictionary, we are still able to step through each value contained within them. Apple can easily change the way the elements are stored within them and it would not affect how we loop through the containers at all. This shows a great decoupling between our code and the container implementations.

If you remember, we were even able to create a generator for the infinite Fibonacci sequence:

struct FibonacciGenerator: GeneratorType {
    typealias Element = Int

    var values = (0, 1)

    mutating func next() -> Element? {
        self.values = (
            self.values.1,
            self.values.0 + self.values.1
        )
        return self.values.0
    }
}

The "container" doesn't even store any elements but we can still iterate through them as if it did.

The iterator pattern is a great introduction to how we make real world use of design patterns. Stepping through a list is such a common problem that Apple built the pattern directly into Swift.

The other behavioral pattern that we will discuss is called the observer pattern. The basic idea of this pattern is that you have one object that is designed to allow other objects to be notified when something occurs.

class ATM {
    var onCashWithdrawn: ((amount: Double) -> ())?

    func withdrawCash(amount: Double) {
        // other work

        // Notify observer if any
        if let callback = self.onCashWithdrawn {
            callback(amount: amount)
        }
    }
}

class RecordKeeper {
    var transactions = [Double]()

    func watchATM(atm: ATM) {
        atm.onCashWithdrawn = { [weak self] amount in
            self?.transactions.append(amount)
        }
    }
}

class ATMWithdrawalNotificationCenter {
    typealias Callback = (amount: Double) -> ()
    private var observers: [String:Callback] = [:]
    
    func trigger(amount: Double) {
        for (_, callback) in self.observers {
            callback(amount: amount)
        }
    }
    
    func addObserverForKey(key: String, callback: Callback) {
        self.observers[key] = callback
    }
    
    func removeObserverForKey(key: String) {
        self.observers[key] = nil
    }
}

behavioral pattern we will discuss is called the iterator pattern. We are starting with this one because we have actually already made use of this pattern in Chapter 6, Make Swift Work For You – Protocols and Generics. The idea of the iterator pattern is to provide a way to step through the contents of a container independent of the way the elements are represented inside the container.

As we saw, Swift provides us with the basics of this pattern with the GeneratorType and SequenceType protocols. It even implements those protocols for its array and dictionary containers. Even though we don't know how the elements are stored within an array or dictionary, we are still able to step through each value contained within them. Apple can easily change the way the elements are stored within them and it would not affect how we loop through the containers at all. This shows a great decoupling between our code and the container implementations.

If you remember, we were even able to create a generator for the infinite Fibonacci sequence:

struct FibonacciGenerator: GeneratorType {
    typealias Element = Int

    var values = (0, 1)

    mutating func next() -> Element? {
        self.values = (
            self.values.1,
            self.values.0 + self.values.1
        )
        return self.values.0
    }
}

The "container" doesn't even store any elements but we can still iterate through them as if it did.

The iterator pattern is a great introduction to how we make real world use of design patterns. Stepping through a list is such a common problem that Apple built the pattern directly into Swift.

The other behavioral pattern that we will discuss is called the observer pattern. The basic idea of this pattern is that you have one object that is designed to allow other objects to be notified when something occurs.

class ATM {
    var onCashWithdrawn: ((amount: Double) -> ())?

    func withdrawCash(amount: Double) {
        // other work

        // Notify observer if any
        if let callback = self.onCashWithdrawn {
            callback(amount: amount)
        }
    }
}

class RecordKeeper {
    var transactions = [Double]()

    func watchATM(atm: ATM) {
        atm.onCashWithdrawn = { [weak self] amount in
            self?.transactions.append(amount)
        }
    }
}

class ATMWithdrawalNotificationCenter {
    typealias Callback = (amount: Double) -> ()
    private var observers: [String:Callback] = [:]
    
    func trigger(amount: Double) {
        for (_, callback) in self.observers {
            callback(amount: amount)
        }
    }
    
    func addObserverForKey(key: String, callback: Callback) {
        self.observers[key] = callback
    }
    
    func removeObserverForKey(key: String) {
        self.observers[key] = nil
    }
}

behavioral pattern that we will discuss is called the observer pattern. The basic idea of this pattern is that you have one object that is designed to allow other objects to be notified when something occurs.

class ATM {
    var onCashWithdrawn: ((amount: Double) -> ())?

    func withdrawCash(amount: Double) {
        // other work

        // Notify observer if any
        if let callback = self.onCashWithdrawn {
            callback(amount: amount)
        }
    }
}

class RecordKeeper {
    var transactions = [Double]()

    func watchATM(atm: ATM) {
        atm.onCashWithdrawn = { [weak self] amount in
            self?.transactions.append(amount)
        }
    }
}

class ATMWithdrawalNotificationCenter {
    typealias Callback = (amount: Double) -> ()
    private var observers: [String:Callback] = [:]
    
    func trigger(amount: Double) {
        for (_, callback) in self.observers {
            callback(amount: amount)
        }
    }
    
    func addObserverForKey(key: String, callback: Callback) {
        self.observers[key] = callback
    }
    
    func removeObserverForKey(key: String) {
        self.observers[key] = nil
    }
}

The first structural pattern we are going to look at is called the composite pattern. The concept of this pattern is that you have a single object that can be broken down into a collection of objects just like itself. This is like the organization of many large companies. They will have teams that are made up of smaller teams, which are then made up of even smaller teams. Each sub-team is responsible for a small part and they come together to be responsible for a larger part of the company.

Hierarchies

A computer ultimately represents what is on the screen with a grid of pixel data. However, it does not make sense for every program to be concerned with each individual pixel. Instead, most programmers use frameworks, often provided by the operating system, to manipulate what is on the screen at a much higher level. A graphical program is usually given one or more windows to draw within and instead of drawing pixels within a window; a program will usually set up a series of "views". A view will have lots of different properties but they will most importantly have a position, size, and background color.

We can potentially build up an entire window with just a big list of views but programmers have devised a way of using the composite pattern to make the whole process much more intuitive. A view can actually contain other views, which are generally referred to as subviews. In this sense, you can look at any view like a tree of subviews. If you look at the very root of the tree, you will see a complete image of what will be displayed on the window. However, you can look at any of the tree branches or leaves and see a smaller part of that view. This is the same as looking at a large team as a whole versus looking at a small team within that larger team. In all of this, there is no difference between a view at the root of the tree and a view at the leaf of the tree, except the root has more sub-views.

Let's look at our own implementation of a View class:

class View {
    var color: (red: Float, green: Float, blue: Float)
        = (1, 1, 1) // white
    var position: (x: Float, y: Float) = (0, 0)
    var size: (width: Float, height: Float)
    var subviews = [View]()
    
    init(size: (width: Float, height: Float)) {
        self.size = size
    }
}

This is a pretty simple class, but by adding the subviews property, which is an array of additional views, we are using the composite pattern to make this a very powerful class. You can imagine a virtually infinite hierarchy of views that are all contained within a single parent view. That single view could be passed to some other class that could draw the entire hierarchy of views.

As an example, let's set up a view that has red in the left-half, green in the upper-right half, and blue in the lower-right half:

To produce this with our class, we could write a code similar to:

let rootView = View(size: (width: 100, height: 100))

let leftView = View(size: (width: rootView.size.width / 2, height: rootView.size.height))
leftView.color = (red: 1, green: 0, blue: 0)
rootView.subviews.append(leftView)

let rightView = View(size: (width: rootView.size.width / 2, height: rootView.size.height))
rightView.color = (red: 0, green: 0, blue: 1)
rightView.position = (x: rootView.size.width / 2, y: 0)
rootView.subviews.append(rightView)

let upperRightView = View(size: (width: rightView.size.width, height: rootView.size.height / 2))
upperRightView.color = (red: 0, green: 1, blue: 0)
rightView.subviews.append(upperRightView)

In this implementation, we actually have a red left half as defined by leftView and a blue right half as defined by rightView. The reason the upper-right half is green instead of blue is that we added upperRightView as a subview to rightView and only made it half the height. This means that our view hierarchy looks similar to the following image:

It is important to note that the position of upperRightView is left at 0, 0. That is because the positioning of all sub-views will always be relative to their immediate parent view. This allows us to pull any view out of the hierarchy without affecting any of its sub-views; drawing rightView within rootView will look exactly the same as if it were drawn on its own.

You could also set up separate objects to manage the contents of different subsections of the main view. For example, to create a program like Xcode, we might have one object that manages the contents of the file list on the left and a different object that manages the display of the selected file. Clearly, Xcode is much more complex than that, but it gives us an idea of how we can build incredibly powerful and complex software with relatively simple concepts.

You may, however, have noticed a potential problem with our view class. What would happen if we added a view to its own subview hierarchy somewhere. That is most likely going to cause an infinite loop when another part of our code goes to draw the view. As another challenge to you, try to update our View class to prevent this from happening. I suggest you start by making subviews private and providing methods for adding and removing subviews. You will probably also want to add an optional superview property that will reference the parent view.

struct Sentence {
    var words: [String]
    
    enum Type: String {
        case Statement = "."
        case Question = "?"
        case Exclamation = "!"
    }
    
    var type: Type
}

struct Sentence {
    // ..

    var string: String {
        return self.words.joinWithSeparator(" ")
            + self.type.rawValue
    }
}

let sentence = Sentence(words: [
    "This", "is",
    "a", "sentence"
], type: .Statement)
print(sentence.string) // "This is a sentence."

One of the most commonly used design patterns in Apple's frameworks is called the delegate pattern. The idea behind it is that you set up an object to let another object handle some of its responsibilities. In other words, one object will delegate some of its responsibilities to another object. This is like a manager hiring employees to do a job that the manager cannot or does not want to do themselves.

As a more technical example, on iOS, Apple provides a user interface class called UITableView. As the name suggest, this class provides us with an easy way to draw a list of elements. On its own, a UITableView isn't enough to make an interface. It needs data to display and it needs to be able to handle all kinds of user interactions, such as tapping, reordering, deleting, and so on.

One instinct is to create your own subclass of UITableView, maybe something like PeopleTableView. This is an OK option until you remember how we discussed that subclassing is actually the strongest type of coupling between two objects. In order to properly subclass a UITableView, you would have to be pretty intimately aware of how the superclass works. This is especially difficult when you are not even allowed to see the code of the superclass.

Another option is to set data on the table view and use the observer pattern to handle user interactions. This is better than the subclassing option, but most data you will want to display is not static and therefore it would be cumbersome to make updates to the table view. It will also still be hard to implement an object that can be reused easily for other ways of displaying a list of information.

So instead, what Apple did is, they created two different properties on UITableView: delegate and dataSource. These properties are there so that we can assign our own objects to handle various responsibilities for the table. The data source is primarily responsible for providing the information to be shown in the table and the delegate's responsibility is to handle user interaction. Of course, if these objects could be of any type, the table view would not really be able to interact with them. Also, if these objects were of a specific type, we would still run into the same subclassing problem. Instead, they are defined to implement the UITableViewDelegate and UITableViewDataSource protocols respectively.

These protocols define only the methods necessary to allow the table view to properly function. This means that the delegate and dataSource properties can be any type as long as they implement the necessary methods. For example, one of the critical methods the data source must implement is tableView:numberOfRowsInSection:. This method provides the table view and an integer referring to the section that it wants to know about. It requires that an integer be returned for the number of rows in the referenced section. This is only one of multiple methods that data source must implement, but it gives you an idea of how the table view no longer has to figure out what data it contains. It simply asks the data source to figure it out.

This provides a very loosely coupled way to implement a specific table view and this same pattern is reused all over the programming world. You would be amazed at what Apple has been able to do with its table view, with very little to no pain inflicted on third party developers. The table view is incredibly optimized to handle thousands upon thousands of rows if you really wanted it to. The table has also changed a lot since the first developer kit for iOS, but these protocols have very rarely been changed except to add additional features.

Model view controller is one of the highest levels and most abstract design patterns. Variations of it are pervasive across a huge percentage of software, especially Apple's frameworks. It really can be considered the foundational pattern for how all of Apple's code is designed and therefore how most third party developers design their own code. The core concept of model view controller is that you split all of your types into three categories, often referred to as layers: model, view, and controller.

The model layer is for all of the types that represent and manipulate data. This layer is the real foundation of what your software can do for its user, so it is also often referred to as the business logic. For example, the model layer from an address book app would have types representing contacts, groups, and so on. It would also contain logic to create, delete, modify, and store those types.

The view layer is for all types involved in the display and interaction of your software. It consists of types like tables, text view, and buttons. Essentially, this layer is responsible for displaying information to the user and providing the affordances for how a user can interact with your application. The view in an address book app would consist of the displayed list of contacts, groups, and contact information.

The final layer, controller, is mostly just the glue code between the model and view layers. It will instruct the view of what to display based on the data in the model layer and it will trigger the right business logic depending on the interactions coming from the view layer. In our address book example, the controller layer would connect something such as a contact add button in the view, to the logic defined in the model for creating a new contact. It will also connect things like the on screen table view to the list of contacts in the model.

In the ideal implementation of model view controller, no model type should ever have any knowledge of the existence of a view type and no view type should know about a model type. Often, a model view controller is visualized sort of like a cake:

The user sees and interacts with the top of the cake and each layer only communicates with its adjacent layers. This means that all communication between the view and the model layers should go through the controller layer. At the same time, the controller layer should be pretty lightweight, because the model layer is doing the heavy lifting on the logic side of the application and the view layer is doing the heavy lifting on drawing to the screen and accepting user input.

One of the main benefits of this design pattern is that it provides a logical and consistent way to break down many pieces of software. This greatly increases your ability to share your code with other developers and understand their code. It gives everyone a frame of reference for when they try to understand another large code base that they haven't seen before. The naming of classes also gives strong clues to developers about what role a type will play in the overall system. Virtually every view class in iOS has the word "view" in it: UITableView, UIView, UICollectionViewCell, etc. Also, most of the controller layer classes that Apple provides have the word controller in them: UIViewController, UITableViewController, MFMailComposeViewController, etc. The model layer is mostly left to third party developers, other than the basic data types, since Apple isn't going to be able to help much with the business logic of your software. However, even among third party developers, these classes are often nouns named after the data they are representing or manipulating: Person, AddressBook, Publisher, and so on.

Another huge benefit of model view controller is that most components will be very reusable. You should be able to easily reuse views with different types of data like you can use a table view to display virtually any kind of data without changing the table view type and you should be able to display something like an address book in lots of different ways without changing the address book type.

As useful as this pattern is, it is also extremely hard to stick to. You will probably spend your entire development career evolving your sense for how to effectively breakdown your problems into these layers. It is often helpful to create explicit folders for each layer, forcing yourself to put every type into only one of the categories. You will also probably find yourself creating a bloated controller layer, especially in iOS, because it is often convenient to stick business logic there. More than any other design pattern, model view controller is probably the one that can be most described as something you strive for but rarely ever perfectly achieve.

first structural pattern we are going to look at is called the composite pattern. The concept of this pattern is that you have a single object that can be broken down into a collection of objects just like itself. This is like the organization of many large companies. They will have teams that are made up of smaller teams, which are then made up of even smaller teams. Each sub-team is responsible for a small part and they come together to be responsible for a larger part of the company.

Hierarchies

A computer ultimately represents what is on the screen with a grid of pixel data. However, it does not make sense for every program to be concerned with each individual pixel. Instead, most programmers use frameworks, often provided by the operating system, to manipulate what is on the screen at a much higher level. A graphical program is usually given one or more windows to draw within and instead of drawing pixels within a window; a program will usually set up a series of "views". A view will have lots of different properties but they will most importantly have a position, size, and background color.

We can potentially build up an entire window with just a big list of views but programmers have devised a way of using the composite pattern to make the whole process much more intuitive. A view can actually contain other views, which are generally referred to as subviews. In this sense, you can look at any view like a tree of subviews. If you look at the very root of the tree, you will see a complete image of what will be displayed on the window. However, you can look at any of the tree branches or leaves and see a smaller part of that view. This is the same as looking at a large team as a whole versus looking at a small team within that larger team. In all of this, there is no difference between a view at the root of the tree and a view at the leaf of the tree, except the root has more sub-views.

Let's look at our own implementation of a View class:

class View {
    var color: (red: Float, green: Float, blue: Float)
        = (1, 1, 1) // white
    var position: (x: Float, y: Float) = (0, 0)
    var size: (width: Float, height: Float)
    var subviews = [View]()
    
    init(size: (width: Float, height: Float)) {
        self.size = size
    }
}

This is a pretty simple class, but by adding the subviews property, which is an array of additional views, we are using the composite pattern to make this a very powerful class. You can imagine a virtually infinite hierarchy of views that are all contained within a single parent view. That single view could be passed to some other class that could draw the entire hierarchy of views.

As an example, let's set up a view that has red in the left-half, green in the upper-right half, and blue in the lower-right half:

To produce this with our class, we could write a code similar to:

let rootView = View(size: (width: 100, height: 100))

let leftView = View(size: (width: rootView.size.width / 2, height: rootView.size.height))
leftView.color = (red: 1, green: 0, blue: 0)
rootView.subviews.append(leftView)

let rightView = View(size: (width: rootView.size.width / 2, height: rootView.size.height))
rightView.color = (red: 0, green: 0, blue: 1)
rightView.position = (x: rootView.size.width / 2, y: 0)
rootView.subviews.append(rightView)

let upperRightView = View(size: (width: rightView.size.width, height: rootView.size.height / 2))
upperRightView.color = (red: 0, green: 1, blue: 0)
rightView.subviews.append(upperRightView)

In this implementation, we actually have a red left half as defined by leftView and a blue right half as defined by rightView. The reason the upper-right half is green instead of blue is that we added upperRightView as a subview to rightView and only made it half the height. This means that our view hierarchy looks similar to the following image:

It is important to note that the position of upperRightView is left at 0, 0. That is because the positioning of all sub-views will always be relative to their immediate parent view. This allows us to pull any view out of the hierarchy without affecting any of its sub-views; drawing rightView within rootView will look exactly the same as if it were drawn on its own.

You could also set up separate objects to manage the contents of different subsections of the main view. For example, to create a program like Xcode, we might have one object that manages the contents of the file list on the left and a different object that manages the display of the selected file. Clearly, Xcode is much more complex than that, but it gives us an idea of how we can build incredibly powerful and complex software with relatively simple concepts.

You may, however, have noticed a potential problem with our view class. What would happen if we added a view to its own subview hierarchy somewhere. That is most likely going to cause an infinite loop when another part of our code goes to draw the view. As another challenge to you, try to update our View class to prevent this from happening. I suggest you start by making subviews private and providing methods for adding and removing subviews. You will probably also want to add an optional superview property that will reference the parent view.

struct Sentence {
    var words: [String]
    
    enum Type: String {
        case Statement = "."
        case Question = "?"
        case Exclamation = "!"
    }
    
    var type: Type
}

struct Sentence {
    // ..

    var string: String {
        return self.words.joinWithSeparator(" ")
            + self.type.rawValue
    }
}

let sentence = Sentence(words: [
    "This", "is",
    "a", "sentence"
], type: .Statement)
print(sentence.string) // "This is a sentence."

One of the most commonly used design patterns in Apple's frameworks is called the delegate pattern. The idea behind it is that you set up an object to let another object handle some of its responsibilities. In other words, one object will delegate some of its responsibilities to another object. This is like a manager hiring employees to do a job that the manager cannot or does not want to do themselves.

As a more technical example, on iOS, Apple provides a user interface class called UITableView. As the name suggest, this class provides us with an easy way to draw a list of elements. On its own, a UITableView isn't enough to make an interface. It needs data to display and it needs to be able to handle all kinds of user interactions, such as tapping, reordering, deleting, and so on.

One instinct is to create your own subclass of UITableView, maybe something like PeopleTableView. This is an OK option until you remember how we discussed that subclassing is actually the strongest type of coupling between two objects. In order to properly subclass a UITableView, you would have to be pretty intimately aware of how the superclass works. This is especially difficult when you are not even allowed to see the code of the superclass.

Another option is to set data on the table view and use the observer pattern to handle user interactions. This is better than the subclassing option, but most data you will want to display is not static and therefore it would be cumbersome to make updates to the table view. It will also still be hard to implement an object that can be reused easily for other ways of displaying a list of information.

So instead, what Apple did is, they created two different properties on UITableView: delegate and dataSource. These properties are there so that we can assign our own objects to handle various responsibilities for the table. The data source is primarily responsible for providing the information to be shown in the table and the delegate's responsibility is to handle user interaction. Of course, if these objects could be of any type, the table view would not really be able to interact with them. Also, if these objects were of a specific type, we would still run into the same subclassing problem. Instead, they are defined to implement the UITableViewDelegate and UITableViewDataSource protocols respectively.

These protocols define only the methods necessary to allow the table view to properly function. This means that the delegate and dataSource properties can be any type as long as they implement the necessary methods. For example, one of the critical methods the data source must implement is tableView:numberOfRowsInSection:. This method provides the table view and an integer referring to the section that it wants to know about. It requires that an integer be returned for the number of rows in the referenced section. This is only one of multiple methods that data source must implement, but it gives you an idea of how the table view no longer has to figure out what data it contains. It simply asks the data source to figure it out.

This provides a very loosely coupled way to implement a specific table view and this same pattern is reused all over the programming world. You would be amazed at what Apple has been able to do with its table view, with very little to no pain inflicted on third party developers. The table view is incredibly optimized to handle thousands upon thousands of rows if you really wanted it to. The table has also changed a lot since the first developer kit for iOS, but these protocols have very rarely been changed except to add additional features.

Model view controller is one of the highest levels and most abstract design patterns. Variations of it are pervasive across a huge percentage of software, especially Apple's frameworks. It really can be considered the foundational pattern for how all of Apple's code is designed and therefore how most third party developers design their own code. The core concept of model view controller is that you split all of your types into three categories, often referred to as layers: model, view, and controller.

The model layer is for all of the types that represent and manipulate data. This layer is the real foundation of what your software can do for its user, so it is also often referred to as the business logic. For example, the model layer from an address book app would have types representing contacts, groups, and so on. It would also contain logic to create, delete, modify, and store those types.

The view layer is for all types involved in the display and interaction of your software. It consists of types like tables, text view, and buttons. Essentially, this layer is responsible for displaying information to the user and providing the affordances for how a user can interact with your application. The view in an address book app would consist of the displayed list of contacts, groups, and contact information.

The final layer, controller, is mostly just the glue code between the model and view layers. It will instruct the view of what to display based on the data in the model layer and it will trigger the right business logic depending on the interactions coming from the view layer. In our address book example, the controller layer would connect something such as a contact add button in the view, to the logic defined in the model for creating a new contact. It will also connect things like the on screen table view to the list of contacts in the model.

In the ideal implementation of model view controller, no model type should ever have any knowledge of the existence of a view type and no view type should know about a model type. Often, a model view controller is visualized sort of like a cake:

The user sees and interacts with the top of the cake and each layer only communicates with its adjacent layers. This means that all communication between the view and the model layers should go through the controller layer. At the same time, the controller layer should be pretty lightweight, because the model layer is doing the heavy lifting on the logic side of the application and the view layer is doing the heavy lifting on drawing to the screen and accepting user input.

One of the main benefits of this design pattern is that it provides a logical and consistent way to break down many pieces of software. This greatly increases your ability to share your code with other developers and understand their code. It gives everyone a frame of reference for when they try to understand another large code base that they haven't seen before. The naming of classes also gives strong clues to developers about what role a type will play in the overall system. Virtually every view class in iOS has the word "view" in it: UITableView, UIView, UICollectionViewCell, etc. Also, most of the controller layer classes that Apple provides have the word controller in them: UIViewController, UITableViewController, MFMailComposeViewController, etc. The model layer is mostly left to third party developers, other than the basic data types, since Apple isn't going to be able to help much with the business logic of your software. However, even among third party developers, these classes are often nouns named after the data they are representing or manipulating: Person, AddressBook, Publisher, and so on.

Another huge benefit of model view controller is that most components will be very reusable. You should be able to easily reuse views with different types of data like you can use a table view to display virtually any kind of data without changing the table view type and you should be able to display something like an address book in lots of different ways without changing the address book type.

As useful as this pattern is, it is also extremely hard to stick to. You will probably spend your entire development career evolving your sense for how to effectively breakdown your problems into these layers. It is often helpful to create explicit folders for each layer, forcing yourself to put every type into only one of the categories. You will also probably find yourself creating a bloated controller layer, especially in iOS, because it is often convenient to stick business logic there. More than any other design pattern, model view controller is probably the one that can be most described as something you strive for but rarely ever perfectly achieve.

One of the most commonly used design patterns in Apple's frameworks is called the delegate pattern. The idea behind it is that you set up an object to let another object handle some of its responsibilities. In other words, one object will delegate some of its responsibilities to another object. This is like a manager hiring employees to do a job that the manager cannot or does not want to do themselves.

As a more technical example, on iOS, Apple provides a user interface class called UITableView. As the name suggest, this class provides us with an easy way to draw a list of elements. On its own, a UITableView isn't enough to make an interface. It needs data to display and it needs to be able to handle all kinds of user interactions, such as tapping, reordering, deleting, and so on.

One instinct is to create your own subclass of UITableView, maybe something like PeopleTableView. This is an OK option until you remember how we discussed that subclassing is actually the strongest type of coupling between two objects. In order to properly subclass a UITableView, you would have to be pretty intimately aware of how the superclass works. This is especially difficult when you are not even allowed to see the code of the superclass.

Another option is to set data on the table view and use the observer pattern to handle user interactions. This is better than the subclassing option, but most data you will want to display is not static and therefore it would be cumbersome to make updates to the table view. It will also still be hard to implement an object that can be reused easily for other ways of displaying a list of information.

So instead, what Apple did is, they created two different properties on UITableView: delegate and dataSource. These properties are there so that we can assign our own objects to handle various responsibilities for the table. The data source is primarily responsible for providing the information to be shown in the table and the delegate's responsibility is to handle user interaction. Of course, if these objects could be of any type, the table view would not really be able to interact with them. Also, if these objects were of a specific type, we would still run into the same subclassing problem. Instead, they are defined to implement the UITableViewDelegate and UITableViewDataSource protocols respectively.

These protocols define only the methods necessary to allow the table view to properly function. This means that the delegate and dataSource properties can be any type as long as they implement the necessary methods. For example, one of the critical methods the data source must implement is tableView:numberOfRowsInSection:. This method provides the table view and an integer referring to the section that it wants to know about. It requires that an integer be returned for the number of rows in the referenced section. This is only one of multiple methods that data source must implement, but it gives you an idea of how the table view no longer has to figure out what data it contains. It simply asks the data source to figure it out.

This provides a very loosely coupled way to implement a specific table view and this same pattern is reused all over the programming world. You would be amazed at what Apple has been able to do with its table view, with very little to no pain inflicted on third party developers. The table view is incredibly optimized to handle thousands upon thousands of rows if you really wanted it to. The table has also changed a lot since the first developer kit for iOS, but these protocols have very rarely been changed except to add additional features.

Model view controller is one of the highest levels and most abstract design patterns. Variations of it are pervasive across a huge percentage of software, especially Apple's frameworks. It really can be considered the foundational pattern for how all of Apple's code is designed and therefore how most third party developers design their own code. The core concept of model view controller is that you split all of your types into three categories, often referred to as layers: model, view, and controller.

The model layer is for all of the types that represent and manipulate data. This layer is the real foundation of what your software can do for its user, so it is also often referred to as the business logic. For example, the model layer from an address book app would have types representing contacts, groups, and so on. It would also contain logic to create, delete, modify, and store those types.

The view layer is for all types involved in the display and interaction of your software. It consists of types like tables, text view, and buttons. Essentially, this layer is responsible for displaying information to the user and providing the affordances for how a user can interact with your application. The view in an address book app would consist of the displayed list of contacts, groups, and contact information.

The final layer, controller, is mostly just the glue code between the model and view layers. It will instruct the view of what to display based on the data in the model layer and it will trigger the right business logic depending on the interactions coming from the view layer. In our address book example, the controller layer would connect something such as a contact add button in the view, to the logic defined in the model for creating a new contact. It will also connect things like the on screen table view to the list of contacts in the model.

In the ideal implementation of model view controller, no model type should ever have any knowledge of the existence of a view type and no view type should know about a model type. Often, a model view controller is visualized sort of like a cake:

The user sees and interacts with the top of the cake and each layer only communicates with its adjacent layers. This means that all communication between the view and the model layers should go through the controller layer. At the same time, the controller layer should be pretty lightweight, because the model layer is doing the heavy lifting on the logic side of the application and the view layer is doing the heavy lifting on drawing to the screen and accepting user input.

One of the main benefits of this design pattern is that it provides a logical and consistent way to break down many pieces of software. This greatly increases your ability to share your code with other developers and understand their code. It gives everyone a frame of reference for when they try to understand another large code base that they haven't seen before. The naming of classes also gives strong clues to developers about what role a type will play in the overall system. Virtually every view class in iOS has the word "view" in it: UITableView, UIView, UICollectionViewCell, etc. Also, most of the controller layer classes that Apple provides have the word controller in them: UIViewController, UITableViewController, MFMailComposeViewController, etc. The model layer is mostly left to third party developers, other than the basic data types, since Apple isn't going to be able to help much with the business logic of your software. However, even among third party developers, these classes are often nouns named after the data they are representing or manipulating: Person, AddressBook, Publisher, and so on.

Another huge benefit of model view controller is that most components will be very reusable. You should be able to easily reuse views with different types of data like you can use a table view to display virtually any kind of data without changing the table view type and you should be able to display something like an address book in lots of different ways without changing the address book type.

As useful as this pattern is, it is also extremely hard to stick to. You will probably spend your entire development career evolving your sense for how to effectively breakdown your problems into these layers. It is often helpful to create explicit folders for each layer, forcing yourself to put every type into only one of the categories. You will also probably find yourself creating a bloated controller layer, especially in iOS, because it is often convenient to stick business logic there. More than any other design pattern, model view controller is probably the one that can be most described as something you strive for but rarely ever perfectly achieve.

One of the most commonly used design patterns in Apple's frameworks is called the delegate pattern. The idea behind it is that you set up an object to let another object handle some of its responsibilities. In other words, one object will delegate some of its responsibilities to another object. This is like a manager hiring employees to do a job that the manager cannot or does not want to do themselves.

As a more technical example, on iOS, Apple provides a user interface class called UITableView. As the name suggest, this class provides us with an easy way to draw a list of elements. On its own, a UITableView isn't enough to make an interface. It needs data to display and it needs to be able to handle all kinds of user interactions, such as tapping, reordering, deleting, and so on.

One instinct is to create your own subclass of UITableView, maybe something like PeopleTableView. This is an OK option until you remember how we discussed that subclassing is actually the strongest type of coupling between two objects. In order to properly subclass a UITableView, you would have to be pretty intimately aware of how the superclass works. This is especially difficult when you are not even allowed to see the code of the superclass.

Another option is to set data on the table view and use the observer pattern to handle user interactions. This is better than the subclassing option, but most data you will want to display is not static and therefore it would be cumbersome to make updates to the table view. It will also still be hard to implement an object that can be reused easily for other ways of displaying a list of information.

So instead, what Apple did is, they created two different properties on UITableView: delegate and dataSource. These properties are there so that we can assign our own objects to handle various responsibilities for the table. The data source is primarily responsible for providing the information to be shown in the table and the delegate's responsibility is to handle user interaction. Of course, if these objects could be of any type, the table view would not really be able to interact with them. Also, if these objects were of a specific type, we would still run into the same subclassing problem. Instead, they are defined to implement the UITableViewDelegate and UITableViewDataSource protocols respectively.

These protocols define only the methods necessary to allow the table view to properly function. This means that the delegate and dataSource properties can be any type as long as they implement the necessary methods. For example, one of the critical methods the data source must implement is tableView:numberOfRowsInSection:. This method provides the table view and an integer referring to the section that it wants to know about. It requires that an integer be returned for the number of rows in the referenced section. This is only one of multiple methods that data source must implement, but it gives you an idea of how the table view no longer has to figure out what data it contains. It simply asks the data source to figure it out.

This provides a very loosely coupled way to implement a specific table view and this same pattern is reused all over the programming world. You would be amazed at what Apple has been able to do with its table view, with very little to no pain inflicted on third party developers. The table view is incredibly optimized to handle thousands upon thousands of rows if you really wanted it to. The table has also changed a lot since the first developer kit for iOS, but these protocols have very rarely been changed except to add additional features.

Model view controller is one of the highest levels and most abstract design patterns. Variations of it are pervasive across a huge percentage of software, especially Apple's frameworks. It really can be considered the foundational pattern for how all of Apple's code is designed and therefore how most third party developers design their own code. The core concept of model view controller is that you split all of your types into three categories, often referred to as layers: model, view, and controller.

The model layer is for all of the types that represent and manipulate data. This layer is the real foundation of what your software can do for its user, so it is also often referred to as the business logic. For example, the model layer from an address book app would have types representing contacts, groups, and so on. It would also contain logic to create, delete, modify, and store those types.

The view layer is for all types involved in the display and interaction of your software. It consists of types like tables, text view, and buttons. Essentially, this layer is responsible for displaying information to the user and providing the affordances for how a user can interact with your application. The view in an address book app would consist of the displayed list of contacts, groups, and contact information.

The final layer, controller, is mostly just the glue code between the model and view layers. It will instruct the view of what to display based on the data in the model layer and it will trigger the right business logic depending on the interactions coming from the view layer. In our address book example, the controller layer would connect something such as a contact add button in the view, to the logic defined in the model for creating a new contact. It will also connect things like the on screen table view to the list of contacts in the model.

In the ideal implementation of model view controller, no model type should ever have any knowledge of the existence of a view type and no view type should know about a model type. Often, a model view controller is visualized sort of like a cake:

The user sees and interacts with the top of the cake and each layer only communicates with its adjacent layers. This means that all communication between the view and the model layers should go through the controller layer. At the same time, the controller layer should be pretty lightweight, because the model layer is doing the heavy lifting on the logic side of the application and the view layer is doing the heavy lifting on drawing to the screen and accepting user input.

One of the main benefits of this design pattern is that it provides a logical and consistent way to break down many pieces of software. This greatly increases your ability to share your code with other developers and understand their code. It gives everyone a frame of reference for when they try to understand another large code base that they haven't seen before. The naming of classes also gives strong clues to developers about what role a type will play in the overall system. Virtually every view class in iOS has the word "view" in it: UITableView, UIView, UICollectionViewCell, etc. Also, most of the controller layer classes that Apple provides have the word controller in them: UIViewController, UITableViewController, MFMailComposeViewController, etc. The model layer is mostly left to third party developers, other than the basic data types, since Apple isn't going to be able to help much with the business logic of your software. However, even among third party developers, these classes are often nouns named after the data they are representing or manipulating: Person, AddressBook, Publisher, and so on.

Another huge benefit of model view controller is that most components will be very reusable. You should be able to easily reuse views with different types of data like you can use a table view to display virtually any kind of data without changing the table view type and you should be able to display something like an address book in lots of different ways without changing the address book type.

As useful as this pattern is, it is also extremely hard to stick to. You will probably spend your entire development career evolving your sense for how to effectively breakdown your problems into these layers. It is often helpful to create explicit folders for each layer, forcing yourself to put every type into only one of the categories. You will also probably find yourself creating a bloated controller layer, especially in iOS, because it is often convenient to stick business logic there. More than any other design pattern, model view controller is probably the one that can be most described as something you strive for but rarely ever perfectly achieve.

commonly used design patterns in Apple's frameworks is called the delegate pattern. The idea behind it is that you set up an object to let another object handle some of its responsibilities. In other words, one object will delegate some of its responsibilities to another object. This is like a manager hiring employees to do a job that the manager cannot or does not want to do themselves.

As a more technical example, on iOS, Apple provides a user interface class called UITableView. As the name suggest, this class provides us with an easy way to draw a list of elements. On its own, a UITableView isn't enough to make an interface. It needs data to display and it needs to be able to handle all kinds of user interactions, such as tapping, reordering, deleting, and so on.

One instinct is to create your own subclass of UITableView, maybe something like PeopleTableView. This is an OK option until you remember how we discussed that subclassing is actually the strongest type of coupling between two objects. In order to properly subclass a UITableView, you would have to be pretty intimately aware of how the superclass works. This is especially difficult when you are not even allowed to see the code of the superclass.

Another option is to set data on the table view and use the observer pattern to handle user interactions. This is better than the subclassing option, but most data you will want to display is not static and therefore it would be cumbersome to make updates to the table view. It will also still be hard to implement an object that can be reused easily for other ways of displaying a list of information.

So instead, what Apple did is, they created two different properties on UITableView: delegate and dataSource. These properties are there so that we can assign our own objects to handle various responsibilities for the table. The data source is primarily responsible for providing the information to be shown in the table and the delegate's responsibility is to handle user interaction. Of course, if these objects could be of any type, the table view would not really be able to interact with them. Also, if these objects were of a specific type, we would still run into the same subclassing problem. Instead, they are defined to implement the UITableViewDelegate and UITableViewDataSource protocols respectively.

These protocols define only the methods necessary to allow the table view to properly function. This means that the delegate and dataSource properties can be any type as long as they implement the necessary methods. For example, one of the critical methods the data source must implement is tableView:numberOfRowsInSection:. This method provides the table view and an integer referring to the section that it wants to know about. It requires that an integer be returned for the number of rows in the referenced section. This is only one of multiple methods that data source must implement, but it gives you an idea of how the table view no longer has to figure out what data it contains. It simply asks the data source to figure it out.

This provides a very loosely coupled way to implement a specific table view and this same pattern is reused all over the programming world. You would be amazed at what Apple has been able to do with its table view, with very little to no pain inflicted on third party developers. The table view is incredibly optimized to handle thousands upon thousands of rows if you really wanted it to. The table has also changed a lot since the first developer kit for iOS, but these protocols have very rarely been changed except to add additional features.

Model view controller is one of the highest levels and most abstract design patterns. Variations of it are pervasive across a huge percentage of software, especially Apple's frameworks. It really can be considered the foundational pattern for how all of Apple's code is designed and therefore how most third party developers design their own code. The core concept of model view controller is that you split all of your types into three categories, often referred to as layers: model, view, and controller.

The model layer is for all of the types that represent and manipulate data. This layer is the real foundation of what your software can do for its user, so it is also often referred to as the business logic. For example, the model layer from an address book app would have types representing contacts, groups, and so on. It would also contain logic to create, delete, modify, and store those types.

The view layer is for all types involved in the display and interaction of your software. It consists of types like tables, text view, and buttons. Essentially, this layer is responsible for displaying information to the user and providing the affordances for how a user can interact with your application. The view in an address book app would consist of the displayed list of contacts, groups, and contact information.

The final layer, controller, is mostly just the glue code between the model and view layers. It will instruct the view of what to display based on the data in the model layer and it will trigger the right business logic depending on the interactions coming from the view layer. In our address book example, the controller layer would connect something such as a contact add button in the view, to the logic defined in the model for creating a new contact. It will also connect things like the on screen table view to the list of contacts in the model.

In the ideal implementation of model view controller, no model type should ever have any knowledge of the existence of a view type and no view type should know about a model type. Often, a model view controller is visualized sort of like a cake:

The user sees and interacts with the top of the cake and each layer only communicates with its adjacent layers. This means that all communication between the view and the model layers should go through the controller layer. At the same time, the controller layer should be pretty lightweight, because the model layer is doing the heavy lifting on the logic side of the application and the view layer is doing the heavy lifting on drawing to the screen and accepting user input.

One of the main benefits of this design pattern is that it provides a logical and consistent way to break down many pieces of software. This greatly increases your ability to share your code with other developers and understand their code. It gives everyone a frame of reference for when they try to understand another large code base that they haven't seen before. The naming of classes also gives strong clues to developers about what role a type will play in the overall system. Virtually every view class in iOS has the word "view" in it: UITableView, UIView, UICollectionViewCell, etc. Also, most of the controller layer classes that Apple provides have the word controller in them: UIViewController, UITableViewController, MFMailComposeViewController, etc. The model layer is mostly left to third party developers, other than the basic data types, since Apple isn't going to be able to help much with the business logic of your software. However, even among third party developers, these classes are often nouns named after the data they are representing or manipulating: Person, AddressBook, Publisher, and so on.

Another huge benefit of model view controller is that most components will be very reusable. You should be able to easily reuse views with different types of data like you can use a table view to display virtually any kind of data without changing the table view type and you should be able to display something like an address book in lots of different ways without changing the address book type.

As useful as this pattern is, it is also extremely hard to stick to. You will probably spend your entire development career evolving your sense for how to effectively breakdown your problems into these layers. It is often helpful to create explicit folders for each layer, forcing yourself to put every type into only one of the categories. You will also probably find yourself creating a bloated controller layer, especially in iOS, because it is often convenient to stick business logic there. More than any other design pattern, model view controller is probably the one that can be most described as something you strive for but rarely ever perfectly achieve.

of the highest levels and most abstract design patterns. Variations of it are pervasive across a huge percentage of software, especially Apple's frameworks. It really can be considered the foundational pattern for how all of Apple's code is designed and therefore how most third party developers design their own code. The core concept of model view controller is that you split all of your types into three categories, often referred to as layers: model, view, and controller.

The model layer is for all of the types that represent and manipulate data. This layer is the real foundation of what your software can do for its user, so it is also often referred to as the business logic. For example, the model layer from an address book app would have types representing contacts, groups, and so on. It would also contain logic to create, delete, modify, and store those types.

The view layer is for all types involved in the display and interaction of your software. It consists of types like tables, text view, and buttons. Essentially, this layer is responsible for displaying information to the user and providing the affordances for how a user can interact with your application. The view in an address book app would consist of the displayed list of contacts, groups, and contact information.

The final layer, controller, is mostly just the glue code between the model and view layers. It will instruct the view of what to display based on the data in the model layer and it will trigger the right business logic depending on the interactions coming from the view layer. In our address book example, the controller layer would connect something such as a contact add button in the view, to the logic defined in the model for creating a new contact. It will also connect things like the on screen table view to the list of contacts in the model.

In the ideal implementation of model view controller, no model type should ever have any knowledge of the existence of a view type and no view type should know about a model type. Often, a model view controller is visualized sort of like a cake:

The user sees and interacts with the top of the cake and each layer only communicates with its adjacent layers. This means that all communication between the view and the model layers should go through the controller layer. At the same time, the controller layer should be pretty lightweight, because the model layer is doing the heavy lifting on the logic side of the application and the view layer is doing the heavy lifting on drawing to the screen and accepting user input.

One of the main benefits of this design pattern is that it provides a logical and consistent way to break down many pieces of software. This greatly increases your ability to share your code with other developers and understand their code. It gives everyone a frame of reference for when they try to understand another large code base that they haven't seen before. The naming of classes also gives strong clues to developers about what role a type will play in the overall system. Virtually every view class in iOS has the word "view" in it: UITableView, UIView, UICollectionViewCell, etc. Also, most of the controller layer classes that Apple provides have the word controller in them: UIViewController, UITableViewController, MFMailComposeViewController, etc. The model layer is mostly left to third party developers, other than the basic data types, since Apple isn't going to be able to help much with the business logic of your software. However, even among third party developers, these classes are often nouns named after the data they are representing or manipulating: Person, AddressBook, Publisher, and so on.

Another huge benefit of model view controller is that most components will be very reusable. You should be able to easily reuse views with different types of data like you can use a table view to display virtually any kind of data without changing the table view type and you should be able to display something like an address book in lots of different ways without changing the address book type.

As useful as this pattern is, it is also extremely hard to stick to. You will probably spend your entire development career evolving your sense for how to effectively breakdown your problems into these layers. It is often helpful to create explicit folders for each layer, forcing yourself to put every type into only one of the categories. You will also probably find yourself creating a bloated controller layer, especially in iOS, because it is often convenient to stick business logic there. More than any other design pattern, model view controller is probably the one that can be most described as something you strive for but rarely ever perfectly achieve.

The first patterns we will discuss are the singleton and shared instance patterns. We are discussing them together because they are extremely similar. First we will discuss shared instance, because it is the less strict form of the singleton pattern.

The idea of the shared instance pattern is that you provide an instance of your class to be used by other parts of your code. Let's look at a quick example of this in Swift:

class AddressBook {
    static let sharedInstance = AddressBook()

    func logContacts() {
        // ...
    }
}

Here, we have a simple address book class but we are providing a static constant called sharedInstance that any other code can use without having to create its own instance. This is a very convenient way to allow otherwise separate code to collaborate. Instead of having to pass around a reference to the same instance all over your code, any code can refer the shared instance right through the class itself:

AddressBook.sharedInstance.logContacts()

Now, the different thing about the singleton pattern is that you would write your code in such a way that it is not even possible to create a second instance of your class. Even though our preceding address book class provides a shared instance, there is nothing to stop someone from creating their own instance using the normal initializers. We could pretty easily change our address book class to a singleton instead of a shared instance, as shown:

class AddressBook {
    static let singleton = AddressBook()

    private init() {}
    
    func logContacts() {
        // ...
    }
}

AddressBook.singelton.logContacts()

Besides changing the name of the static constant, the only difference with this code is that we declared the initializers as private. This makes it so that no code outside of this file can use the initializer and therefore, no code outside of this file can create a new instance.

The singleton pattern is great for when multiple instances of the same class are going to cause a problem. This is especially important for classes that represent a finite physical resource but it can also be a way to simplify a class that would be more difficult and unnecessary to implement in a way that would allow multiple instances. For example, there isn't actually much of a reason to ensure there is only ever one address book in an application. Perhaps the user will want to have two address books: one for business and one for personal. They should be able to operate independently as long as they are working from a different file, but maybe in your application you know that there will only ever be a single address book and it always has to be driven by a single file. Instead of requiring your code to create an address book with a specific file path, and instead of dealing with the danger of having multiple instances reading and writing to the same file, you can use the singleton version above and have the file path be fixed.

In fact, the singleton and shared instance patterns are so convenient that many developers over use them. So let's discuss some of the drawbacks of these patterns. It is nice to be able to access an instance from anywhere, but when it is easy to do so, it is also easy to create a very complex web of dependencies on that object. That goes against the principle of low coupling that we are trying to achieve. Imagine trying to change a singleton class when you have 20 different pieces of code all using it directly.

Using these patterns can also create hidden dependencies. Usually, it is pretty clear what dependencies an instance has based on what it must be initialized with, but a singleton or shared instance does not get passed into the initializer, so it can often go unnoticed as a dependency. Even though there is some initial extra overhead to passing an object into an initializer, it will often reduce the coupling and maintain a clearer picture of how your types interact. The bottom line is, like with any other pattern, think carefully about each use of the singleton and shared instance patterns and be sure it is the best tool for the job.

The final pattern we will discuss here is called abstract factory. It is based on a simpler pattern called factory. The idea of a factory pattern is that you implement an object for creating other objects, much like you would create a factory for assembling cars. The factory pattern is great when the initializing of a type is very complex or you want to create a bunch of similar objects. Let's take a look at the second scenario. What if we were creating a two-player ping-pong game and we had some scenario in the game where we would add additional balls that a specific player needed to keep in play? The ball class might look something like this:

struct Ball {
    let color: String
    let owningPlayer: Int
}

Every time we needed a new ball we could assign a new color and owning player to it. Or, we could create a separate ball factory for each player:

struct BallFactory {
    let color: String
    let owningPlayer: Int

    func createNewBall() -> Ball {
        return Ball(
            color: self.color,
            owningPlayer: self.owningPlayer
        )
    }
}

let player1Factory = BallFactory(
    color: "Red", owningPlayer: 1
)
let player2Factory = BallFactory(
    color: "Green", owningPlayer: 1
)

let ball1 = player1Factory.createNewBall()

Now, we could pass this factory into whatever object is responsible for handling the ball creation event and that object is no longer responsible for determining the color of the ball or any other properties we might want. This is great for reducing the number of responsibilities that object has and also keeps the code very flexible to add additional ball properties in the future without having to change the ball creation event object.

An abstract factory is a special form of factory where the instances the factory creates may be one of many subclasses of a single other class. A great example of this would be an image creation factory. As we discussed in Chapter 3, One Piece at a Time – Types, Scopes, and Projects, computers have an enormous number of ways to represent images. In that chapter we hypothesized having a superclass called just "Image" that would have a subclass for each type of image. This would help us write classes to handle any type of image very easily by always having them work with the image superclass. Similarly, we could create an image factory that would virtually eliminate any need for an external type to know anything about the different types of images. We could design an abstract factory that takes the path to any image, loads the image into the appropriate subclass, and returns it simply as the image superclass. Now, neither the code that loads an image, nor the code that uses the image, needs to know what type of image they are dealing with. All of the complexity of different image representations is abstracted away inside the factory and the image class hierarchy. This is a huge win for making our code easier to understand and more maintainable.

first patterns we will discuss are the singleton and shared instance patterns. We are discussing them together because they are extremely similar. First we will discuss shared instance, because it is the less strict form of the singleton pattern.

The idea of the shared instance pattern is that you provide an instance of your class to be used by other parts of your code. Let's look at a quick example of this in Swift:

class AddressBook {
    static let sharedInstance = AddressBook()

    func logContacts() {
        // ...
    }
}

Here, we have a simple address book class but we are providing a static constant called sharedInstance that any other code can use without having to create its own instance. This is a very convenient way to allow otherwise separate code to collaborate. Instead of having to pass around a reference to the same instance all over your code, any code can refer the shared instance right through the class itself:

AddressBook.sharedInstance.logContacts()

Now, the different thing about the singleton pattern is that you would write your code in such a way that it is not even possible to create a second instance of your class. Even though our preceding address book class provides a shared instance, there is nothing to stop someone from creating their own instance using the normal initializers. We could pretty easily change our address book class to a singleton instead of a shared instance, as shown:

class AddressBook {
    static let singleton = AddressBook()

    private init() {}
    
    func logContacts() {
        // ...
    }
}

AddressBook.singelton.logContacts()

Besides changing the name of the static constant, the only difference with this code is that we declared the initializers as private. This makes it so that no code outside of this file can use the initializer and therefore, no code outside of this file can create a new instance.

The singleton pattern is great for when multiple instances of the same class are going to cause a problem. This is especially important for classes that represent a finite physical resource but it can also be a way to simplify a class that would be more difficult and unnecessary to implement in a way that would allow multiple instances. For example, there isn't actually much of a reason to ensure there is only ever one address book in an application. Perhaps the user will want to have two address books: one for business and one for personal. They should be able to operate independently as long as they are working from a different file, but maybe in your application you know that there will only ever be a single address book and it always has to be driven by a single file. Instead of requiring your code to create an address book with a specific file path, and instead of dealing with the danger of having multiple instances reading and writing to the same file, you can use the singleton version above and have the file path be fixed.

In fact, the singleton and shared instance patterns are so convenient that many developers over use them. So let's discuss some of the drawbacks of these patterns. It is nice to be able to access an instance from anywhere, but when it is easy to do so, it is also easy to create a very complex web of dependencies on that object. That goes against the principle of low coupling that we are trying to achieve. Imagine trying to change a singleton class when you have 20 different pieces of code all using it directly.

Using these patterns can also create hidden dependencies. Usually, it is pretty clear what dependencies an instance has based on what it must be initialized with, but a singleton or shared instance does not get passed into the initializer, so it can often go unnoticed as a dependency. Even though there is some initial extra overhead to passing an object into an initializer, it will often reduce the coupling and maintain a clearer picture of how your types interact. The bottom line is, like with any other pattern, think carefully about each use of the singleton and shared instance patterns and be sure it is the best tool for the job.

The final pattern we will discuss here is called abstract factory. It is based on a simpler pattern called factory. The idea of a factory pattern is that you implement an object for creating other objects, much like you would create a factory for assembling cars. The factory pattern is great when the initializing of a type is very complex or you want to create a bunch of similar objects. Let's take a look at the second scenario. What if we were creating a two-player ping-pong game and we had some scenario in the game where we would add additional balls that a specific player needed to keep in play? The ball class might look something like this:

struct Ball {
    let color: String
    let owningPlayer: Int
}

Every time we needed a new ball we could assign a new color and owning player to it. Or, we could create a separate ball factory for each player:

struct BallFactory {
    let color: String
    let owningPlayer: Int

    func createNewBall() -> Ball {
        return Ball(
            color: self.color,
            owningPlayer: self.owningPlayer
        )
    }
}

let player1Factory = BallFactory(
    color: "Red", owningPlayer: 1
)
let player2Factory = BallFactory(
    color: "Green", owningPlayer: 1
)

let ball1 = player1Factory.createNewBall()

Now, we could pass this factory into whatever object is responsible for handling the ball creation event and that object is no longer responsible for determining the color of the ball or any other properties we might want. This is great for reducing the number of responsibilities that object has and also keeps the code very flexible to add additional ball properties in the future without having to change the ball creation event object.

An abstract factory is a special form of factory where the instances the factory creates may be one of many subclasses of a single other class. A great example of this would be an image creation factory. As we discussed in Chapter 3, One Piece at a Time – Types, Scopes, and Projects, computers have an enormous number of ways to represent images. In that chapter we hypothesized having a superclass called just "Image" that would have a subclass for each type of image. This would help us write classes to handle any type of image very easily by always having them work with the image superclass. Similarly, we could create an image factory that would virtually eliminate any need for an external type to know anything about the different types of images. We could design an abstract factory that takes the path to any image, loads the image into the appropriate subclass, and returns it simply as the image superclass. Now, neither the code that loads an image, nor the code that uses the image, needs to know what type of image they are dealing with. All of the complexity of different image representations is abstracted away inside the factory and the image class hierarchy. This is a huge win for making our code easier to understand and more maintainable.

pattern we will discuss here is called abstract factory. It is based on a simpler pattern called factory. The idea of a factory pattern is that you implement an object for creating other objects, much like you would create a factory for assembling cars. The factory pattern is great when the initializing of a type is very complex or you want to create a bunch of similar objects. Let's take a look at the second scenario. What if we were creating a two-player ping-pong game and we had some scenario in the game where we would add additional balls that a specific player needed to keep in play? The ball class might look something like this:

struct Ball {
    let color: String
    let owningPlayer: Int
}

Every time we needed a new ball we could assign a new color and owning player to it. Or, we could create a separate ball factory for each player:

struct BallFactory {
    let color: String
    let owningPlayer: Int

    func createNewBall() -> Ball {
        return Ball(
            color: self.color,
            owningPlayer: self.owningPlayer
        )
    }
}

let player1Factory = BallFactory(
    color: "Red", owningPlayer: 1
)
let player2Factory = BallFactory(
    color: "Green", owningPlayer: 1
)

let ball1 = player1Factory.createNewBall()

Now, we could pass this factory into whatever object is responsible for handling the ball creation event and that object is no longer responsible for determining the color of the ball or any other properties we might want. This is great for reducing the number of responsibilities that object has and also keeps the code very flexible to add additional ball properties in the future without having to change the ball creation event object.

An abstract factory is a special form of factory where the instances the factory creates may be one of many subclasses of a single other class. A great example of this would be an image creation factory. As we discussed in Chapter 3, One Piece at a Time – Types, Scopes, and Projects, computers have an enormous number of ways to represent images. In that chapter we hypothesized having a superclass called just "Image" that would have a subclass for each type of image. This would help us write classes to handle any type of image very easily by always having them work with the image superclass. Similarly, we could create an image factory that would virtually eliminate any need for an external type to know anything about the different types of images. We could design an abstract factory that takes the path to any image, loads the image into the appropriate subclass, and returns it simply as the image superclass. Now, neither the code that loads an image, nor the code that uses the image, needs to know what type of image they are dealing with. All of the complexity of different image representations is abstracted away inside the factory and the image class hierarchy. This is a huge win for making our code easier to understand and more maintainable.

We have already seen in Chapter 3, One Piece at a Time – Types, Scopes, and Projects that we can use an enumeration with associated values to represent a measurement like distance in multiple measurement systems:

enum Height {
    case Imperial(feet: Int, Inches: Double)
    case Metric(meters: Double)
    case Other(String)
}

We can generalize this use case as using an enumeration to flatten out a simple class hierarchy. Instead of the enumeration, we could have created a height superclass or protocol with subclasses for each measurement system. However, this would be a more complex solution and we would lose the benefits of using a value type instead of a reference type. The enumeration solution is also very compact, making it very easy to understand at a glance instead of having to analyze how multiple different classes fit together.

Let's look at an even more complex example. Let's say we want to create a fitness app and we want to be able to track multiple types of workouts. Sometimes people workout to do a certain number of repetitions of various movements; other times they are just going for a certain amount of time. We could create a class hierarchy for this, but an enumeration with associated values works great:

enum Workout {
    case ForTime(seconds: Int)
    case ForReps(movements: [(name: String, reps: Int)])
}

Now, when we want to create a workout, we only need to define values relevant to the type of workout we are interested in without having to use any classes at all.

Another great use of enumerations with associated values is to represent the state of something. The simplest example of this would be a result enumeration that can either contain a value or an error description if an error occurs:

enum NumberResult {
    case Success(value: Int)
    case Failure(reason: String)
}

This allows us to write a function that can fail and give a reason that it failed:

func divide(first: Int, by second: Int) -> NumberResult {
    guard second != 0 else {
        return .Failure(reason: "Cannot divide by zero")
    }
    return .Success(value: first / second)
}

This is an alternative to normal error handling and can make sense for functions where the failure case is treated similarly to a success case instead of as a rare exception.

A slightly more complex idea is to use an enumeration to represent a process that will go through various stages over time, often called a state machine. We could write an enumeration for the process of a download:

enum DownloadState {
    case Pending
    case InProgress(percentComplete: Float)
    case Complete(data: String)
}

While the download is in progress we can access how complete it is and once it is complete we can access the data that it downloaded. This information is only accessible when it is applicable. This enumeration will also make it easier to make sure our download is always in a reasonable and clearly defined state. There is no possibility for a middle ground where, for example, the download might be complete but the data hasn't been processed yet. If we wanted to represent an additional processing step, we could easily add another case and it would be clear from then on out that a download will go through that additional state.

have already seen in Chapter 3, One Piece at a Time – Types, Scopes, and Projects that we can use an enumeration with associated values to represent a measurement like distance in multiple measurement systems:

enum Height {
    case Imperial(feet: Int, Inches: Double)
    case Metric(meters: Double)
    case Other(String)
}

We can generalize this use case as using an enumeration to flatten out a simple class hierarchy. Instead of the enumeration, we could have created a height superclass or protocol with subclasses for each measurement system. However, this would be a more complex solution and we would lose the benefits of using a value type instead of a reference type. The enumeration solution is also very compact, making it very easy to understand at a glance instead of having to analyze how multiple different classes fit together.

Let's look at an even more complex example. Let's say we want to create a fitness app and we want to be able to track multiple types of workouts. Sometimes people workout to do a certain number of repetitions of various movements; other times they are just going for a certain amount of time. We could create a class hierarchy for this, but an enumeration with associated values works great:

enum Workout {
    case ForTime(seconds: Int)
    case ForReps(movements: [(name: String, reps: Int)])
}

Now, when we want to create a workout, we only need to define values relevant to the type of workout we are interested in without having to use any classes at all.

Another great use of enumerations with associated values is to represent the state of something. The simplest example of this would be a result enumeration that can either contain a value or an error description if an error occurs:

enum NumberResult {
    case Success(value: Int)
    case Failure(reason: String)
}

This allows us to write a function that can fail and give a reason that it failed:

func divide(first: Int, by second: Int) -> NumberResult {
    guard second != 0 else {
        return .Failure(reason: "Cannot divide by zero")
    }
    return .Success(value: first / second)
}

This is an alternative to normal error handling and can make sense for functions where the failure case is treated similarly to a success case instead of as a rare exception.

A slightly more complex idea is to use an enumeration to represent a process that will go through various stages over time, often called a state machine. We could write an enumeration for the process of a download:

enum DownloadState {
    case Pending
    case InProgress(percentComplete: Float)
    case Complete(data: String)
}

While the download is in progress we can access how complete it is and once it is complete we can access the data that it downloaded. This information is only accessible when it is applicable. This enumeration will also make it easier to make sure our download is always in a reasonable and clearly defined state. There is no possibility for a middle ground where, for example, the download might be complete but the data hasn't been processed yet. If we wanted to represent an additional processing step, we could easily add another case and it would be clear from then on out that a download will go through that additional state.

use of enumerations with associated values is to represent the state of something. The simplest example of this would be a result enumeration that can either contain a value or an error description if an error occurs:

enum NumberResult {
    case Success(value: Int)
    case Failure(reason: String)
}

This allows us to write a function that can fail and give a reason that it failed:

func divide(first: Int, by second: Int) -> NumberResult {
    guard second != 0 else {
        return .Failure(reason: "Cannot divide by zero")
    }
    return .Success(value: first / second)
}

This is an alternative to normal error handling and can make sense for functions where the failure case is treated similarly to a success case instead of as a rare exception.

A slightly more complex idea is to use an enumeration to represent a process that will go through various stages over time, often called a state machine. We could write an enumeration for the process of a download:

enum DownloadState {
    case Pending
    case InProgress(percentComplete: Float)
    case Complete(data: String)
}

While the download is in progress we can access how complete it is and once it is complete we can access the data that it downloaded. This information is only accessible when it is applicable. This enumeration will also make it easier to make sure our download is always in a reasonable and clearly defined state. There is no possibility for a middle ground where, for example, the download might be complete but the data hasn't been processed yet. If we wanted to represent an additional processing step, we could easily add another case and it would be clear from then on out that a download will go through that additional state.

The most obvious way to use lazy properties is to avoid unnecessary memory usage. Let's look at a very simple example first:

struct MyType {
    lazy var largeString = "Some String"
}
let instance = MyType()

Even though we created a new instance of MyType in the preceding code, largeString is not set until we try to access it. This is great if we have a large variable that may not be needed on every instance. Until it is accessed, it is not taking up any memory.

We can also take this idea of a lazy property even further using a closure to calculate the value:

class Directory {
    lazy var subFolders: [Directory] = {
        var loaded = [Directory]()
        // Load subfolders into 'loaded'
        return loaded
    }()
}

Here we are actually making use of a self-evaluating closure. We did this by adding the open and close parentheses to the end of the closure. By doing this, we are assigning the subFolders property to the result of executing the closure; because it is a lazy property, the closure will not be executed until the subFolders property is accessed for the first time. Just like the plain lazy property that can help us avoid taking up unnecessary memory, this technique allows us to avoid running time-consuming operations when we don't have to.

An alternative to using lazy properties to achieve our goals above would be to use optional properties instead and simply assign those values later as needed. This is an OK solution, especially if our only goal is to reduce unnecessary memory usage or processing. However, there is one other great benefit to the lazy property solution. It produces more legible code by connecting the logic to calculate a property's value right by its definition. If we simply had an optional property it would have to be initialized in either an initializer or by some other method. It would not be immediately clear when looking at the property what its value will be and when it will be set, if it will be set at all.

This is a critically important advantage as your code base grows in size and age. It is very easy to get lost in a code base, even if it is your own. The more straight lines you can draw from one piece of logic to another, the easier it will be able to find the logic you are looking for when you come back to your code base later.

most obvious way to use lazy properties is to avoid unnecessary memory usage. Let's look at a very simple example first:

struct MyType {
    lazy var largeString = "Some String"
}
let instance = MyType()

Even though we created a new instance of MyType in the preceding code, largeString is not set until we try to access it. This is great if we have a large variable that may not be needed on every instance. Until it is accessed, it is not taking up any memory.

We can also take this idea of a lazy property even further using a closure to calculate the value:

class Directory {
    lazy var subFolders: [Directory] = {
        var loaded = [Directory]()
        // Load subfolders into 'loaded'
        return loaded
    }()
}

Here we are actually making use of a self-evaluating closure. We did this by adding the open and close parentheses to the end of the closure. By doing this, we are assigning the subFolders property to the result of executing the closure; because it is a lazy property, the closure will not be executed until the subFolders property is accessed for the first time. Just like the plain lazy property that can help us avoid taking up unnecessary memory, this technique allows us to avoid running time-consuming operations when we don't have to.

An alternative to using lazy properties to achieve our goals above would be to use optional properties instead and simply assign those values later as needed. This is an OK solution, especially if our only goal is to reduce unnecessary memory usage or processing. However, there is one other great benefit to the lazy property solution. It produces more legible code by connecting the logic to calculate a property's value right by its definition. If we simply had an optional property it would have to be initialized in either an initializer or by some other method. It would not be immediately clear when looking at the property what its value will be and when it will be set, if it will be set at all.

This is a critically important advantage as your code base grows in size and age. It is very easy to get lost in a code base, even if it is your own. The more straight lines you can draw from one piece of logic to another, the easier it will be able to find the logic you are looking for when you come back to your code base later.

also take this idea of a lazy property even further using a closure to calculate the value:

class Directory {
    lazy var subFolders: [Directory] = {
        var loaded = [Directory]()
        // Load subfolders into 'loaded'
        return loaded
    }()
}

Here we are actually making use of a self-evaluating closure. We did this by adding the open and close parentheses to the end of the closure. By doing this, we are assigning the subFolders property to the result of executing the closure; because it is a lazy property, the closure will not be executed until the subFolders property is accessed for the first time. Just like the plain lazy property that can help us avoid taking up unnecessary memory, this technique allows us to avoid running time-consuming operations when we don't have to.

An alternative to using lazy properties to achieve our goals above would be to use optional properties instead and simply assign those values later as needed. This is an OK solution, especially if our only goal is to reduce unnecessary memory usage or processing. However, there is one other great benefit to the lazy property solution. It produces more legible code by connecting the logic to calculate a property's value right by its definition. If we simply had an optional property it would have to be initialized in either an initializer or by some other method. It would not be immediately clear when looking at the property what its value will be and when it will be set, if it will be set at all.

This is a critically important advantage as your code base grows in size and age. It is very easy to get lost in a code base, even if it is your own. The more straight lines you can draw from one piece of logic to another, the easier it will be able to find the logic you are looking for when you come back to your code base later.

alternative to using lazy properties to achieve our goals above would be to use optional properties instead and simply assign those values later as needed. This is an OK solution, especially if our only goal is to reduce unnecessary memory usage or processing. However, there is one other great benefit to the lazy property solution. It produces more legible code by connecting the logic to calculate a property's value right by its definition. If we simply had an optional property it would have to be initialized in either an initializer or by some other method. It would not be immediately clear when looking at the property what its value will be and when it will be set, if it will be set at all.

This is a critically important advantage as your code base grows in size and age. It is very easy to get lost in a code base, even if it is your own. The more straight lines you can draw from one piece of logic to another, the easier it will be able to find the logic you are looking for when you come back to your code base later.