You're an iOS developer. How would you set up a class to notify another object of an event?
In the context of iOS development, a few options may come to mind when
answering this question:
blocks/closures, or delegation. By far, the most popular answer I've
received in interviews is delegation, which is understandable given
the frequent use of the delegate pattern in iOS APIs. However, there
is a difference between notification and delegation, just as the names
Two Obvious Differences
When asking why you might prefer notifications or delegates, a common
observation is that notifications can be sent to multiple targets, but
delegation only allows for a single target. So if an object is using
a delegate protocol as a means of notification, it can only have one
object listening for those "notifications". Posting notifications
NotificationCenter allows for multiple listeners.
Someone who has a little more experience might also recognize that
NotificationCenter provides loose coupling between the
object that sends the notification and the object that responds
to it. Neither object needs to know anything about the other. With
delegation, there is often tighter coupling between the class that
receives the delegate and the implementation of the delegate protocol.
However, these observations actually point to conceptual differences between notification and delegation. It can be a bit misleading to think of delegation as a means of sending notifications between two objects. Rather, delegation should be thought of as a means for implementing functionality that an object leaves undefined. One object is delegating certain responsibilities to another object, which allows the object to become more flexible and general-purpose. The Apple documentation expresses it this way:
Delegation is a simple and powerful pattern in which one object in a program acts on behalf of, or in coordination with, another object.
UITableView and its delegate,
UITableViewDelegate. Every table view must be able to create
and configure the cells it displays. However, it's not possible for
UITableView to know how to create and configure custom table
view cells. Therefore,
UITableView delegates that
responsibility to another object through
Using delegation allows you to compose complex objects from simpler
objects. In the
UITableView example, we are composing a
complete table view implementation from an instance of
UITableView and object instances that implement
UITableViewDelegate. In theory you can swap out distinct
UITableViewDataSource. In such a scenario, it should become
clear that delegation is not used for notification but for rounding out
functionality that isn't known to the delegating object. The object
and the delegate work together as a cohesive unit, each necessarily
complementing the other.
In some respects, delegation provides functionality similar to inheritance in object-oriented class heirarchies. A base class may define abstract methods that are implemented in derived classes. The distinction becomes one of using composition (via delegates) versus inheritance (via class heirarchies). One of the benefits of using composition is that delegate implementations can be used with other objects that use the same delegate interface and delegate implementations can be swapped out without needing to recreate derived class instances.
emailTableView.dataSource = personalAccountDataSource emailTableView.delegate = detailedCellDelegate emailTableView.dataSource = businessAccountDataSource emailTableView.delegate = summaryCellDelegate
In this snippet of code, we can see the possibility of completely rebuilding a table view by simply switching its data source and delegate implementations.
A Source of Confusion
One of the reasons we might confuse delegation with notification is that iOS delegates often have a "notification feel" to them. For instance, the table view delegate defines the following methods:
func tableView(UITableView, willSelectRowAt: IndexPath) // Tells the delegate that a specified row is about to be selected. func tableView(UITableView, didSelectRowAt: IndexPath) // Tells the delegate that the specified row is now selected. func tableView(UITableView, willDeselectRowAt: IndexPath) // Tells the delegate that a specified row is about to be deselected. func tableView(UITableView, didDeselectRowAt: IndexPath) // Tells the delegate that the specified row is now deselected.
Because these methods are called in response to user interaction with the table view, they seem to be notifications that are triggered by a user-initiated event.
The Nature of Notifications
How can we draw a distinction between delegation and notification if the line between them can become so fuzzy? Here's another comment from the Apple documentation:
These recipients of the notification, known as observers, can adjust their own appearance, behavior, and state in response to the event.
There's an interesting choice of phrasing there - "[they] can adjust their own appearance, behavior, and state." When we implement a notification observer, it responds to events by altering itself. When we implement a delegate, it responds to events by altering the appearance, behavior, and state of its associated object.
Okay. Delegates aren't notifiers. But do I really care? Maybe not. If you know how to do what you want to do, perhaps it doesn't really matter. However, when we're building applications with other engineers, it can become important to communicate in a way that is clear to both parties. If I say we should implement a notification for an event, I'm not suggesting a new delegate method. Similarly, if you suggest adding a delegate, you're envisioning two tightly coupled objects that are working together.
So here are a few ideas you can keep in mind regarding common distinctions:
|Tightly coupled objects||Loosely coupled objects|
|Single delegate||Multiple observers|
|Alters sender's behavior and state||Alters the receiver's behavior and state|
During my early experience with iOS, I was frustrated by some common uses of delegation and really wanted one-to-many notifications. However, understanding the intention behind delegation (it's completing functionality, not sending a notification) has gone a long way to improving my understanding when building iOS apps.