concept protocol in category swift

This is an excerpt from Manning's book Swift in Depth. Login to get full access to this book.

1.3.3. Protocols are tricky

Protocols are the big selling point of Swift. But once you start working with protocols, you will hit sharp edges and cut yourself from time to time. Things that “should just work” somehow don’t. Protocols are great in their current state and already good enough for creating quality software, but sometimes you hit a wall, and you’ll have to use workarounds—of which this book shares plenty.

Protocols bring a lot of power and flexibility to your code. Some might say it’s Swift’s flagship feature, especially since Apple markets Swift as a protocol-oriented-programming language. But as lovely as protocols are, they can become difficult fast. Plenty of subtleties are involved, such as using protocols at runtime or compile time, and constraining protocols with associated types.

This chapter’s goal is to lay down a solid foundation regarding protocols; it will shed light on using protocols as an interface versus using protocols to constrain generics. This chapter also aims to carry you over the hump of what can be considered advanced protocols, which are protocols with associated types. The end goal is to make sure you understand why, when, and how to apply protocols (and generics) in multiple scenarios. The only requirements are that you’re at least a little bit familiar with protocols and that you have read chapter 7, “Generics.” After this chapter, protocols and associated types will repeatedly return, so I recommend not to skip this one!

First, you’ll take a look to see how protocols fare by themselves, versus using protocols to constrain generics. You’ll look at both sides of the coin and take on two approaches. One approach uses generics, and the other does not. The aim of this chapter is that you’ll be able to make trade-offs and decide on a proper approach in day-to-day programming.

In the second section, you’ll move on to the more difficult aspect of protocols, which is when you start using associated types. You can consider protocols with associated types as generic protocols, and you’ll discover why you would need them and when you can apply them in your applications.

Once you start passing around protocols with associated types, you’re working with very flexible code. But things will get tricky. You’ll take a closer look to see how to pass protocols with associated types around, and how to create types that store them with constraints. On top of that, you’ll apply a nice trick to clean up your APIs by using a technique called protocol inheritance.

8.3. Passing protocols with associated types

Let’s see the ways you can pass a protocol with associated types around. You’ll use the Worker protocol from the last section with two associated types named Input and Output.

You can use protocols as generic constraints. But protocols can also be used as a type at runtime (dynamic dispatch) when you step away from generics.

Using protocols as a generic constraint is usually the way to go, until you need dynamic dispatch.

Associated types are generics that are tied to a protocol.

Protocols with associated types allow a concrete type to define the associated type. Each concrete type can specialize an associated type to a different type.

Protocols with Self requirements are a unique flavor of associated types referencing the current type.

Protocols with associated types or Self requirements force you to reason about types at compile time.

You can make a protocol inherit another protocol to further constrain its associated types.

You introduce a new Song type, but instead of playing a file at a URL, it uses an AudioFile type. How would you deal with this? See if you can make the protocol reflect this. Answer: You introduce an associated type, such as Media. The contents property is now of type Media, which resolves to something different for each implementation:

protocol Playable {
    associatedtype Media
    var contents: Media { get }
    func play()
}

final class Movie: Playable {
    let contents: URL

    init(contents: URL) {
        self.contents = contents
    }

    func play() { print("Playing video at \(contents)") }
}

struct AudioFile {}
final class Song: Playable {
    let contents: AudioFile

    init(contents: AudioFile) {
        self.contents = contents
    }

    func play() { print("Playing song") }
}

copy

This is an excerpt from Manning's book iOS Development with Swift. Login to get full access to this book.

Protocols are similar to interfaces in other languages. They specify the methods and properties that a type that adopts the protocol will need to implement.

Listing 3.6. Extending a protocol

protocol Telephone { var phoneNo:Int { get set } func makeCall() func hangUp() } extension Telephone { 1 func makeCall() { 2 print("Make call") 2 } 2 func hangUp() { 2 print("Hang up") 2 } 2 } class Landline:Telephone { var phoneNo:Int init(phoneNo:Int) { self.phoneNo = phoneNo } }

copy

1 Extension of protocol

2 Implementation of methods in protocol

Let’s look again at telephones, converting subclasses to is-a and can-do protocols. Figure 3.4 illustrates one way you could redraw their relationships.

Figure 3.4. Telephone using protocols