Delegates - What are they REALLY?

Question

Can anyone out there explain them using analogies to some real-life processes - like running a Baseball team, or a coffee shop, or an Auto-Mechanic's Shop - anything that would MAKE SENSE? Like lets not even talk CODE, or SYNTAX, or programming - I've seen plenty of those posts and none of them really do it for me - can we just talk concepts first?

Like I don't even understand WHY we have them, how they're advantageous, etc.

Show me the real-world analogy of a process run with and without delegates, so I can see what makes them so useful and great.

Then we can code-it-out.

(And FYI, my specific interest is in Objective-C/iPhone App Development implementation - but I really think understanding this conceptually first is much more important.)

thanks in advance!

Answer 1

Not all coding abstractions have a real-life equivalent. For instance, you'd be hard pressed to find a real-life analogy for paged memory. So instead of making a real-life analogy, I'm just going to give you a real-life case of why you need them.

First things first, the actual definition of the verb to delegate (from the Oxford Dictionary):

entrust (a task or responsibility) to another person, typically one who is less senior than oneself : he delegates routine tasks | the power delegated to him must never be misused.

Delegates are objects that are delegated a responsibility, because it didn't make sense from a design perspective to have a single class do all the job.

Let's say you have a UI table class. You want to make it reusable to display many kinds of data: that means, for the most part, that you can't tie it to your model itself. For instance, if you made your UI table specifically to display Album objects (with a name, an artist, etc.) then you wouldn't be able to reuse it to display, say, File objects (with an owner, a document type, etc.): you'd have to edit the class to make it fit. This will duplicate a lot of code, so you should find another mechanism. This leads to a problem: how can it display any kind of data if it's not allowed to tie to the data classes?

The solution is to split the responsibility of getting the data and displaying the data. Since your table needs the data to display it but can't discover it itself because it knows nothing about your model, it should delegate this responsibility to another class, crafted precisely for this purpose, and have it hand the information back in a general form that the table will know how to use.

This means you'll have another class that will respond to a certain number of methods that the table object will use as if it was part of its core behavior (for instance, a method on the delegate to get the name of the columns, another to get a specific row, etc.). For a concrete example, you could look up the NSTableViewDelegate protocol reference: these are the methods NSTableView can call on its delegate to get information about various things or customized behavior. (The tableView: argument basically every method has identifies the table view calling the method. It's often ignored as many table view delegate classes exist to support a single table view.)

Delegates are objects that simply "know better". Your UI table has no clue how to get what it needs, but it has a delegate that "knows better", so it can request the data from it.

You can also use this pattern to handle events: for instance, when a view is clicked, it doesn't know what to do, but maybe it has a delegate that knows what to do.

In other words, delegates are one of a few ways of extending a class's behavior without modifying it or subclassing it.

Answer 2

What are they REALLY?

specialists

---

Customer: Hi - did you fix my car?

Employee: I estimate that we'll have a chance to look at it in less an hour. I'll call you when it's ready.

Customer: I've already waited 30 minutes, and I'm really in a rush!

Employee: We're very busy at this time of year.

Customer: You don't seem busy; you've been at the front desk the entire time!

Employee: I'm not a mechanic. I am the manager. Do you still want me to fix your brakes?

---

The manager's good at what he does; he details problems for the customers, orders blinker fluid, makes the schedule, and does payroll. Although he likes cars and knows a lot about them, he's not a specialist at repairing them. The manager's capable of doing many things at the shop, but it's the mechanics that have the expertise required to fix the customer's brakes.

One of the most common reasons delegation is used is to avoid subclassing (that would be like sending the manager to school to become a mechanic - an analogy which looks a lot like multiple inheritance). When subclassing could be used to specialize, delegation may often be used instead. Delegation is a looser bond where (in a good design) one object fulfills all or most of the duties, but leaves frequently specialized portions of its duties to other implementations (the delegates).