Physical analogy to introduce a Delegate in .Net programming

Question

Delegates are strange beasts (think Pointers with aspirations) and I was planning to introduce them using a physical metaphor: a power strip. The power strip connects to an 'event' (wall socket) and has a 'signature' (the interface of the plug shape and parameters) and provides connectivity to multiple event-handlers (the sockets in the strip), but it doesn't actually "do anything". Other examples would be a USB Hub and a Network Switch (different 'signatures' / plug and socket interface). Delegates can be used for any sort of event situation, not only the Windows GUI, so they are a fairly open-ended idea. ("Can you say 'abstract'? I knew you could.")

This gives something that students can visualize for the terms of a Delegate: what it connects to, how it can provide for multi-cast events, and how methods connect to it. Does this seem like it will work, or is there a better way to introduce this highly abstract yet necessary programming concept?

Answer 1

I know that you are looking for a physical analogy, but I'd say I agree with @ctrl-alt-delor about the 'link to what they already know' part.

I usually start by introducing a simple algorithm, then show how that algorithm can be parameterized. Then we move on to OO, where I discuss how an algorithm can be parameterized with not just a value, but with a piece of code (i.e. creating an interface, and passing an implementation of that interface to a method). For the interface, I always use an analogy like USB.

Then we move on to the delegates, where I introduce delegates as if they were an interface with one method, Invoke(), and whatever you pass to the delegate gets called in that Invoke() method. Then we move on to delegate internals (how they are immutable, and multicast etc.) I also have examples and practices that we do to show them that every solution that uses a delegate can be translated into a more OO version using interfaces (again, referring back to interfaces).

Answer 2

Link to what they have already learnt on the course.

[I have made an assumption, that they have already done this.]

John von Neumann, said it is all data. Data and code are data. We have already learnt to pass data, but what about this other data, the code. We should be able to pass that as well. How can we do it. They are delegate types.

Look at things I can pass to you

• A pen
• A list
• A script for Hamlet

“Simber and the hiyeners enter stage left …” (from the lion king, a variant of hamlet)

What type of object is this? It is a set of instructions. I can pass it around, and ask people to do what it says.

Answer 3

I think your metaphor is currently a bit limited in that it's useful only really in the context of event-oriented programming (and GUIs) and such. After all, delegates are basically anonymous functions and functional programming languages (Haskell, Lisp, etc) make heavy use of anonymous functions to accomplish all sorts of things. (And many mainstream languages do something similar -- see C#'s Linq, for example).

In any case, if you had to give a metaphor, I would reuse whatever metaphor you used to explain objects (or perhaps even use objects themselves as a metaphor!).

After all, an object is a bundle of data and methods that we can pass around. Well, sometimes, we're interested in just one method out of that object. In that case, instead of passing around the whole object, can we just pass a single method?

---

Something I would also consider doing is motivating anonymous functions by introducing basic Linq before moving on to GUIs since it gives your students the opportunity to practice writing code that both creates and uses anonymous functions.

That is, show students a for loop performing some mapping or filtering operation, teach them how to abstract that, then explain that C# already provides two methods that do this: enumerable.Select(...) and enumerable.Where(...).

You can then talk about how the Func<...> and Predicate<...> types and so forth work fine for many cases, but that sometimes you need more descriptive signatures (especially when doing things like GUI programming!). Enter delegates.

This can feel a little backwards because you're presenting these language features in basically the opposite order they were added to C#, but the students don't have to know that.

Answer 4

If you've talked about interfaces, you can simply say that a delegate is like an interface for a single method. Interfaces are "implemented" by classes; delegates are "matched" by methods.

Physically, if an interface is a contract that can be fulfilled (implemented) by a party (class), a delegate is simply a term (of a contract).