Delegate on Andrew Bancroft

What is Delegation? – A Swift Developer’s Guide

Fri, 27 Mar 2015 03:29:01 +0000

Of the major design patterns that are prevalent in iOS development, delegation is one that appears quite often. For many developers entering app development for the iOS platform, dealing with delegates is a new concept. It certainly was for me.

In my analysis of NSNotificationCenter vs Delegation, I wrote some about delegation, but only in comparison to how NSNotificationCenter works. I haven’t yet given delegation dedicated time and analysis, but I intend to do so now.

My aim in this blog entry is to try and make some sense out of the question, “What is delegation?”. Explore with me…

What is the delegation design pattern?

To read that “delegation is a design pattern that [insert explanation here]” never really clicked with me. Many who are new to programming have not dealt extensively with “design patterns”, so it doesn’t always suffice to define delegation in those terms.

I suspect that since Swift has lowered the barrier to entry for iOS development, many who are new to the platform are also new to coding in general, so here’s my attempt to explain what clicked for me regarding what delegation is:

Design pattern

First, take the phrase “design pattern”.

Design implies architecture. It connotes a strategy for organizing something. Design conveys the method by which components will work together to accomplish an end.

Pattern implies that there is some repeatable process that has honed in around a common thread… a common practice… a predictable method for doing something. “Pattern” gives the impression that such a practice has converged over time into something that is now well-known, well-understood, and commonly used. I imagine a sort of “survival of the fittest” approach to process and practice. Things that didn’t converge or that were weaker in the real world fell away and the strongest survived into this thing we call “pattern”.

A design pattern in software terms, then, is a method for architecting, strategizing about, and organizing an application’s code in such a way that has been found to be commonplace, repeatable, and practically sound over time.

Delegation

Now take the word delegation. Three things come to my mind:

The verb, “to delegate”, meaning “to give control”
The noun, “a delegate”, meaning “a person acting for another”
The made-up noun, “a delegat_or_”, or more properly, a principal, meaning “a person who delegates to another”

In the real world, the word delegation encapsulates relationship and responsibility. A delegator/principal (noun) would delegate (verb) control or responsibility to another person called a delegate.

How could we map this to software? Well, it actually falls in line quite nicely.

Rather than people, we’re dealing with instances of classes (or other data structures like structs, but I’m just going to keep it simple and say “class” to encapsulate the idea). For delegation to occur in software, you’d have a situation where one class (a delegator/principal class) would delegate control or responsibility, here meaning behavioral logic, to another class called a delegate.

How is delegation used?

So yes… delegation is a design pattern. It’s a design pattern that exists on other platforms, but it is one that has been heavily adopted by Apple and is ubiquitous throughout the iOS APIs. It’s a design pattern that shifts responsibility from one class to another, thereby creating a separation of responsibilities and concerns. But what kinds of responsibilities and concerns? How is delegation used in practice?

Communication

In practice, delegation is most often used as a way for one class to communicate to another class. Observing some of the actions that delegates perform from Apple’s own APIs give us clues about this. Take the following samples from UITableViewDelegate as an example:

tableView(_:_will_SelectRowAtIndexPath:)
tableView(_:_did_SelectRowAtIndexPath:)
tableView(_:_did_HighlightRowAtIndexPath:)

Or how about a sampling from UIScrollViewDelegate:

scrollView**Did_Scroll**(:)
scrollView**WillBegin_Dragging**(:)
scrollView**WillEnd_Dragging**(:withVelocity:targetContentOffset:)
scrollView**DidEnd_Dragging**(:willDecelerate:)

My observation of Apple’s APIs indicates to me that one of the intended uses for delegation is to allow one instance to communicate back to some other instance that something will/did happen. The table view or scroll view delegates the opportunity to perform some action in response to some lifecycle event to another class, namely, its delegate.

It’s also worth noting the scope of the communication that delegation is intended to be used for. Whereas NSNotificationCenter fits the need for one instance to broadcast a message intended for more than one listening instance, delegation fits the scenario where an instance only needs to send a message to a single listener (the delegate).

Customization

Another common usage for delegation is to provide a delegate instance the opportunity to customize certain aspects of the delegat_ing_ instance’s internal state. Once again, clues from a few of Apple’s APIs shed some light on this usage scenario. Let’s look at UITableViewDelegate first:

tableView(_:heightForRowAtIndexPath:)
tableView(_:editActionsForRowAtIndexPath:)
tableView(_:indentationLevelForRowAtIndexPath:)
tableView(_:shouldHighlightRowAtIndexPath:)

These are all customization-points that a UITableView allows its delegate to have a say in. Some of the methods are so important that the table view can’t display itself unless it gets this information from its delegate. The point here is that the table view is shifting responsibility for the implementation of that logic off to its delegate, allowing for greater controlled flexibility and customization.

Wrapping up

With delegation being such a heavily utilized strategy for organizing an iOS application’s logic, understanding what it is becomes key concern. In this article we unpacked the terms “design pattern” and “delegation” to get a grasp of why those words were chosen to describe the strategy. Finally, we looked at how the delegation pattern is used in practice, observing that two common use-cases for delegation: class-to-class communication and customization.

NSNotificationCenter vs Delegation – An Analysis

Thu, 05 Feb 2015 13:00:26 +0000

In Fundamentals of NSNotificationCenter in Swift, a commenter asked me to elaborate on a response I’d given to a dialog going on below the blog post. I had stated:

If you need a more structured environment around your [instance]-to-[instance] communication, delegates … are probably a better choice [than NSNotificationCenter].

I’ve been thinking for some time since I responded with that comment. What do I mean when I say “if you need a more structured environment”… What does that even look like? Why are delegates a better choice when I need such “structure”?

Structured environment? What’s that?

“Structured environment” may be a bit vague. Here’s what I was thinking when I wrote it: At the time of the comment, I was imagining what a solution implemented with NSNotificationCenter, and a solution implemented with a delegate look like….

Questions

First, I tried to step into the role of each instance, and in a role-playing sort of way, ask:

As a notifier / delegator instance: “What do I expect to happen as I send this notification or invoke this method on my delegate? What clues from my execution context inform that expectation?”
As a notifier / delegator instance: “What control do I appear to have over the sequence of events that happen as a result of sending this notification or invoking this method on my delegate?”
As a listener / delegate instance: “What impact does acting on this notification or executing this delegate method have on the system as a whole?”

And then shifting out of the role-playing mentality, stepping back and asking a question of clarity:

“Which strategy seems to provide greater clarity and structure to the entire application environment?”
“Which strategy would most help another developer who might see this code and try to trace the logic and impact of the code?”

The measurement of a more or less “structured environment”, then, would be influenced by the answers to the questions of expectations, perceived control, impact, and clarity.

Let’s explore some of those answers from the perspective of each communication strategy, starting with NSNotificationCenter.

Answers from the NSNotificationCenter Perspective

With NSNotificationCenter as an instance-to-instance communication strategy, we have the following environment:

Note that Listeners 1 to n may or may not exist. The graphic is assuming that 1+ Listener instances have “tuned in” to a particular notification key.

Expectations

What do I expect to happen? Well, the most reasonable thing I (as a “notifier instance”) can expect is for some other “listener instance” somewhere to tune in to the notification key I’m broadcasting. I have no way of knowing what would happen after that. It’s up to the listener to do something intelligent with the notification that [x event] occurred. I, as a notifier, can expect nothing more.

Perceived Control

It appears that I, as a notifier, have no control over the sequence of events that would occur as a result of my broadcast. That’s by design – the interaction between me and any listener is weak at best.

This can be a fantastic thing! There’s freedom in saying “Hey! This happened!” and then being done. But it’s also “less structured”, as I’m terming it.

Impact

The impact on the system as a whole has the potential to be significant. With NSNotificationCenter, it depends on how many listener instances there are and what each of them does in response to the notification. One could design the system to localize the impacts to the context of the listening instance. I’ve heard of and seen ugly situations that trigger cascading effects that make deciphering the impact of a notification much harder.

Clarity

We lose a good deal of clarity when heavy usage of NSNotificationCenter occurs in an application. There may be appropriate times to use NSNotificationCenter in your app. Keep in mind that it becomes much more difficult to sort out various interactions when more and more listener instances are responding a notification. Trying to reason about how the system as a whole arrived at its current state isn’t as easy when NSNotificationCenter enters the picture. Other developers with less knowledge of the app as a whole would suffer from this loss of clarity.

Answers from the Delegate Perspective

With a delegate, we have a significantly different strategy at hand. To put it before us:

Expectations

The delegation strategy deals with protocols. Protocols by nature give us reliable a way to…

Count on the implementation of needed/expected behavior, and
Predict what the behavior of the adopter of that protocol will be. By practicing good naming conventions, I, as a delegator, find it reasonable to expect that invoking a method on my delegate will do whatever the name of that method implies.

Perceived Control

It would appear that as a delegator, I can control the sequence of events that need to take place by choosing when to invoke methods on my delegate. A strategy using NSNotificationCenter can only send out a notification into the ether, and hope that something acts on it. A strategy using delegation has a delegate which adopts a protocol. Every method is at my disposal to call in whatever order makes sense.

Impact

The impact on the system as a whole still has the potential to be significant. Since there’s one-to-one communication going on between a delegator and its delegate, the determining factor on how broad the impact is tends to lean on the design of the system as a whole. Design patterns that minimize or eliminate global state reduce this potentially broad impact.

One advantage that the delegation pattern has is that the delegate conforms to a protocol and a protocol, along with its specified methods, have names. However small that knowledge is, it could give us clues about what impact of executing the delegate’s methods might have on the system.

Clarity

With the advantage of dealing with intelligently named protocols and clearly outlined method names, the delegation strategy would win the battle of clarity in my opinion. I can look at the delegator instance and say, “When execution of this instance’s logic gets to this point, reliance on the delegate kicks in and [x, y, and z] happens. I can jump over to the delegate’s implementation and say, “[x] does this, [y] does that, and [z] does this other thing.” Other developers with less knowledge of the app as a whole would enjoy this added clarity quite readily.

In Summary

Here, I’ve analyzed NSNotificationCenter, side by side with the delegation pattern, by imagining myself in the role of each instance (notifier, listener | delegator, delegate). I assessed each strategy in terms of expectations, perceived control, impact, and clarity, attempting to shed light on what it means for an environment to be “more structured” or “less structured”. My hope was to shed light on my use of the term “structured environment”, and to share my thoughts on some of the implications of using each strategy.