Delegates to Swift Closure Pattern

Delegation is a simple and powerful pattern in which one object acts on behalf of another object by holding a reference to the delegate, then sending messages through it. This is the pattern Apple has chosen for its frameworks and has worked quite well… a little awkward at first, but eventually makes sense 🙂

Then Swift came along and brought new techniques and patterns due to it’s functional paradigm. The game changed and Apple’s coding conventions are making a slow shift to becoming more Swifty. In this post, I’m going to illustrate how we can convert delegates to a closures-based pattern.

What About Delegates?

Although delegates are powerful, it’s a bit archaic. With reactive and event-driven programing, delegates breaks down and lose its elegance. See this simple delegate pattern example below. Notice how the completed flag gets propagated back to the parent object who was passed into the Todo initializer:

protocol TodoDelegate: class {
    func completed(todo: Todo)
}

struct Todo {
    var id: Int
    var title: String
    
    var completed: Bool = false {
        didSet {
            // Notify delegate of completion
            guard completed else { return }
            delegate?.completed(todo: self)
        }
    }
    
    weak var delegate : TodoDelegate?
    
    init(_ delegate: TodoDelegate, id: Int, title: String) {
        self.delegate = delegate
        self.id = id
        self.title = title
    }
}

class MyParentController: TodoDelegate {
    lazy var todo1: Todo = {
        return Todo(self, id: 1, title: "Todo item 1")
    }()
    
    lazy var todo2: Todo = {
        return Todo(self, id: 2, title: "Todo item 2")
    }()
    
    lazy var todo3: Todo = {
        return Todo(self, id: 3, title: "Todo item 3")
    }()
    
    func completed(todo: Todo) {
        switch todo.id {
        case 1: print("Do something with todo: \(todo.title)")
        case 2: print("Do another thing with todo: \(todo.title)")
        case 3: print("Do final thing with todo: \(todo.title)")
        default: break
        }
    }
}

let controller = MyParentController()
controller.todo1.completed = true
controller.todo2.completed = true
controller.todo3.completed = true

// Prints the following to the console:
// Do something with todo: Todo item 1
// Do something with todo: Todo item 1
// Do final thing with todo: Todo item 3

The Todo objects were instantiated in MyParentController and passed itself in as the delegate. It accepted the delegate as a specific protocol called TodoDelegate. This protocol will indicate to the Todo object what properties and functions the delegate has.

In the complete property of Todo, the didSet event calls the delegate’s completed function. It knows that the completed function is there because MyParentController adopts TodoDelegate.

This is where delegates breaks down. The completed function in MyParentController is being shared for all Todo objects. I have to put a switch statement there to find the one who triggered it and perform the customized action for it. What if we we’re listening to hundreds of Todo objects, that switch statement would get out of control. Even besides this, it feels weird that the Todo object and the triggered function are in two different places.

Delegates to Closure Pattern

We will now convert the above delegate pattern to a closure-based one. This fits more into the functional programming paradigm. Instead of a delegate function getting triggered, we will allow callers to “subscribe” to the Todo object. The subscriptions will take a closure and queue it for later execution when ready:

struct Todo {
    var id: Int
    var title: String
    
    var completed: Bool = false {
        didSet {
            // Notify subscribers of completion
            guard completed else { return }
            handlers.forEach { $0(self) }
        }
    }
    
    // Task queue
    var handlers = [(Todo) -> Void]()
    
    init(id: Int, title: String) {
        self.id = id
        self.title = title
    }
    
    mutating func subscribe(completion: @escaping (Todo) -> Void) {
        handlers += [completion]
    }
}

class MyParentController {
    lazy var todo1: Todo = {
        return Todo(id: 1, title: "Todo item 1")
    }()
    
    lazy var todo2: Todo = {
        return Todo(id: 2, title: "Todo item 2")
    }()
    
    lazy var todo3: Todo = {
        return Todo(id: 3, title: "Todo item 3")
    }()
}

let controller = MyParentController()

controller.todo1.subscribe {
    print("Do something with todo: \($0.title)")
}

controller.todo2.subscribe {
    print("Do another thing with todo: \($0.title)")
}

controller.todo3.subscribe {
    print("Do final thing with todo: \($0.title)")
}

controller.todo1.subscribe {
    print("Another one for fun with todo: \($0.title)")
}

controller.todo1.completed = true
controller.todo2.completed = true
controller.todo3.completed = true

// Prints the following to the console:
// Do something with todo: Todo item 1
// Another one for fun with todo: Todo item 1
// Do another thing with todo: Todo item 1
// Do final thing with todo: Todo item 3

We got rid of the delegate protocol completely. In fact, the Todo objects doesn’t even need a reference to MyParentController at all! Instead, the caller subscribes to the todo’s events:

controller.todo1.subscribe {
    print("Do something with todo: \($0.title)")
}

This is great because now the focus is on the Todo object. It makes more sense to attach a closure to the Todo object itself instead of defining it somewhere else in a shared delegate function.

During the subscribe process, it stores this closure into a queue to be called later when ready:

var handlers = [(Todo) -> Void]()
...
func subscribe(completion: @escaping (Todo) -> Void) {
    handlers += [completion]
}

When it’s time to trigger the event, it executes the closures in the queue one by one:

var completed: Bool = false {
    didSet {
        guard completed else { return }
        handlers.forEach { $0(self) }
    }
}

What About Thread-Safety?

There’s one complication you must handle. The queue is simply an array of closures. This can be dangerous if subscriptions were to happen from multiple threads. Therefore, we need some locking or exclusivity mechanism on the queue. The good news is I have already done this in another post called Creating Thread-Safe Arrays in Swift. We can use the SynchronizedArray from there for our queue type:

var handlers = SynchronizedArray<(Todo) -> Void>()
...
func subscribe(completion: @escaping (Todo) -> Void) {
    handlers += [completion]
}

Everything else stays the same because the SynchronizedArray has many of the same API’s as a regular array, but is thread-safe!

Conclusion

Although this was a simple example, the delegate to closure pattern can be applied to more complex scenarios. For example, imagine you can subscribe to GPS location updates instead of sharing a single delegate function:

locationManager.subscribeLocation {
    print("Location is: \($0)")
}

This becomes even more useful for shared singletons which can only accept one delegate, instead of being able to trigger multiple delegates. In a future post, I’ll convert delegates to closures for native Apple managers like CLLocationManager and CBCentralManager. With a thread-safe queue in place, working with them should feel Swifty and robust.

Happy Coding!!