objc.io

0:09 Today we'll talk about protocols and class hierachies. There was a session at WWDC about protocol-oriented programming, and in that session, they showed how to replace a class hierarchy with protocols. The reason for doing this is that class hierarchies sometimes are very inflexible. One problem that most iOS developers have seen is the GodViewController. All other view controllers are supposed to inherit from GodViewController. That's very limiting, because it doesn't allow you to inherit from UITableViewController anymore (or any other view controller), because Swift has single inheritance.

0:55 With protocols, you can define shared functionality in a more flexible way than in a common super class. The protocol based approach is not without limitations either though, and we'll look at them a bit later.

A Class Hierarchy

1:23 In the example code, we start out with a class hierarchy. We have a Shape class, which is an abstract superclass of sorts. Since Swift doesn't have abstract classes, we just provide implementations that call fatalError in the draw method and in the boundingBox property. Then we have a shared image method, which can be used by all of Shape's subclasses. That's the power of inheritance: you can reuse things you've written in your superclass.

class Shape {
    func draw(context: CGContext) {
        fatalError()
    }

    var boundingBox: CGRect {
        fatalError()
    }

    func image() -> UIImage {
        let renderer = UIGraphicsImageRenderer(bounds: boundingBox)
        return renderer.image { draw(context: $0.cgContext) }
    }
}

2:03 We have two subclasses of Shape. Rectangle inherits from Shape and has additional properties such as origin and size. It also overrides the boundingBox and draw method with specific implementations:

class Rectangle: Shape {
    var origin: CGPoint
    var size: CGSize
    var color: UIColor = .red

    init(origin: CGPoint, size: CGSize) {
        self.origin = origin
        self.size = size
    }

    override var boundingBox: CGRect {
        return CGRect(origin: origin, size: size)
    }

    override func draw(context: CGContext) {
        context.setFillColor(color.cgColor)
        context.fill(boundingBox)
    }
}

The Circle class is similar, but draws circles instead:

class Circle: Shape {
    var center: CGPoint
    var radius: CGFloat
    var color: UIColor = .green

    init(center: CGPoint, radius: CGFloat) {
        self.center = center
        self.radius = radius
    }

    override var boundingBox: CGRect {
        return CGRect(origin: CGPoint(x: center.x-radius, y: center.y-radius), size: CGSize(width: radius*2, height: radius*2))
    }

    override func draw(context: CGContext) {
        context.setFillColor(color.cgColor)
        context.fillEllipse(in: boundingBox)
    }
}

Refactoring to a Protocol-Oriented Approach

2:38 To refactor this into a protocol-oriented approach, we'll change class Shape to protocol Shape, and remove the default implementations for draw and boundingBox. We'll mark the boundingBox property as read-only. The shared image method is moved to a protocol extension:

protocol Shape {
    func draw(context: CGContext)
    var boundingBox: CGRect { get }
}

extension Shape {
    func image() -> UIImage {
        let renderer = UIGraphicsImageRenderer(bounds: boundingBox)
        return renderer.image { draw(context: $0.cgContext) }
    }
}

3:30 In the Rectangle definition, we can leave the first line as it is, because the syntax for subclassing and protocol conformance is the same. We just have to remove the override keywords:

class Rectangle: Shape {
    var origin: CGPoint
    var size: CGSize
    var color: UIColor = .red

    init(origin: CGPoint, size: CGSize) {
        self.origin = origin
        self.size = size
    }

    var boundingBox: CGRect {
        return CGRect(origin: origin, size: size)
    }

    func draw(context: CGContext) {
        context.setFillColor(color.cgColor)
        context.fill(boundingBox)
    }
}

3:50 For Circle, we have to make the same changes. This is all we need to do to create a protocol-oriented version of our code.

4:04 We can take this a bit further, and replace all our classes with structs. We simply change the class keywords to struct and we're done. Even though it's a tiny change at the source level, it has big implications for the code. All of our rectangles and circles are values now, not references. It's not better or worse than having them as reference types, just very different. Defining Shape as a protocol gives us the option to make that change, whereas the inheritance approach requires us to use classes.

Adding Shared Functionality

5:10 Let's extend Shape by adding a method to rotate shapes. As a first attempt, we could add a mutating method to the protocol:

protocol Shape {
    func draw(context: CGContext)
    var boundingBox: CGRect { get }
    mutating func rotate(by angle: CGFloat)
}

5:33 However, now every type needs to implement the rotate method. With two types, we will have duplication, but it'll only get worse when we add more types. It would be nicer to provide a way to implement it once for all Shapes.

6:10 Instead of defining a mutating rotate in the protocol, we define an immutable variant in a protocol extension:

extension Shape {
    func rotated(by angle: CGFloat) -> Shape {
        // ...
    }
}

6:16 For the angle, we currently use a CGFloat. It would be much more precise to use e.g. the Measurement API, because now it's unclear what the unit of the angle is: radians, degrees, or something else. However, we won't fix that today.

6:39 The way we'll implement rotated is by returning a new TransformedShape value. So we'll start by creating TransformedShape, stores the original shape and a CGAffineTransform value:

struct TransformedShape {
    var original: Shape
    var transform: CGAffineTransform
}

7:03 We make TransformedShape conform to Shape in an extension. For the bounding box, we take the original bounding box and apply the transform:

extension TransformedShape: Shape {
    var boundingBox: CGRect {
        return original.boundingBox.applying(transform)
    }

    // ...
}

7:29 The draw method is a bit more complicated. The approach we'll take is to rotate the context, and then call the original draw method. However, because the context is a mutable value, we have to make sure to restore it to the original state after we're done, so that we don't influence other draw methods:

extension TransformedShape: Shape {
    // ...

    func draw(context: CGContext) {
        context.saveGState()
        context.concatenate(transform)
        original.draw(context: context)
        context.restoreGState()
    }
}

8:42 In the rotated method we use TransformedShape's memberwise initializer to create the rotated shape:

extension Shape {
    func rotated(by angle: CGFloat) -> Shape {
        return TransformedShape(original: self, transform: CGAffineTransform(rotationAngle: angle))
    }
}

9:15 To try it out, we modify the sample code to draw a rotated rectangle:

let size = CGSize(width: 100, height: 200)
let rectangle = Rectangle(origin: .zero, size: CGSize(width: 100, height: 200))
rectangle.rotated(by: CGFloat(M_PI/6)).image()

Dispatch in Protocol Extensions

9:43 There are some tricky things to be aware of when working with protocols and protocol extensions. We're going to use a bit of a constructed example to demonstrate those pitfalls, but you'll encounter them sooner or later.

Let's say we want to override the rotated method for Circle, and simply return the Circle directly:

struct Circle: Shape {
    // ...
    func rotated(by angle: CGFloat) -> Shape {
        return self
    }
}

10:26 Now, if we call circle.rotated(by:), we'll see that the overridden rotated method in the Circle struct gets called. However, with protocol-oriented APIs you'll often store conforming entities as the protocol type. In our example this means storing a circle as Shape, not as Circle. If you do this, the custom rotated method won't get called anymore.

11:13 The reason is that methods defined in protocol extensions are statically dispatched. To have dynamic dispatch, we have to add our rotated method to the protocol itself:

protocol Shape {
    func draw(context: CGContext)
    var boundingBox: CGRect { get }
    func rotated(by angle: CGFloat) -> Shape
}

12:04 Now our overridden rotated method gets called again. This also explains why the protocols in the standard library have gotten so large. Even though there are default implementations for most methods in e.g. the Collection protocol, they're added to the protocol to allow for dynamic dispatch. The behavior around static and dynamic dispatch can be unintuitive at first, so it's important to be aware of the two different options.

Discussion

13:02 The protocol-oriented solution we came up with isn't necessarily better or worse. Both protocols and class hierarchies are tools we can use. They both have different tradeoffs. For example, class hierarchies allow you to inherit stored properties, and you can call super when overriding something. In a protocol-oriented approach, this is not possible.

A limitation of class hierarchies is that you can only use single inheritance. If you need shared functionality, you might run into the issue that you want to inherit from multiple classes, and that problem doesn't happen with protocols. With protocols, you can also add conformance later on, whereas with a class hierarchy, you can't replace a superclass unless you own that class. Depending on the problem you're solving, you can explore both solutions.

14:33 A related issue is that you often have to decide whether you need a protocol at all. For example, in the networking episode we have a Resource struct, not a Resource protocol. This is because each resource has the same structure: they all have a URL, a HTTP method and a parse function. In this case it doesn't make sense to define a protocol.

For the example we worked on today, the different types have different properties. For example, a Rectangle has on origin and size, whereas a Circle has a center and radius. Because they have a different structure, protocols are a much better fit.