<p>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.</p>

<p>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.</p>

<p>Then we move on to the delegates, where I introduce delegates as if they were an interface with one method, <code>Invoke()</code>, and whatever you pass to the delegate gets called in that <code>Invoke()</code> 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).</p>

CC BY-SA 3.0
2017-09-26T06:19:23.690Z
2017-09-26T06:19:23.690Z
Akos Nagy
<h1>Link to what they have already learnt on the course.</h1>
<p>[I have made an assumption, that they have already done this.]</p>
<p>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.</p>
<h1>Look at things I can pass to you</h1>
<ul>
<li>A pen</li>
<li>A list</li>
<li>A script for Hamlet</li>
</ul>
<p>“Simber and the hiyeners enter stage left …” (from the lion king, a variant of hamlet)</p>
<p>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.</p>

CC BY-SA 3.0
2017-09-22T18:49:28.730Z
2017-09-22T18:49:28.730Z
2020-06-18T08:36:57.023Z
ctrl-alt-delor
<p>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).</p>

<p>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!). </p>

<p>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?</p>

<hr>

<p>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.</p>

<p>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: <code>enumerable.Select(...)</code> and <code>enumerable.Where(...)</code>.</p>

<p>You can then talk about how the <code>Func&lt;...&gt;</code> and <code>Predicate&lt;...&gt;</code> 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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-09-23T00:18:18.817Z
2017-09-23T00:18:18.817Z
Michael0x2a
<p>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.</p>

<p>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).</p>

CC BY-SA 3.0
2017-10-05T21:17:10.657Z
It's customary to include a comment when downvoting.
G-Wiz
CC BY-SA 3.0
2017-09-27T17:11:06.123Z
2017-09-27T17:11:06.123Z
G-Wiz
<p>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 <em>any</em> 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.")</p>

<p>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?</p>

CC BY-SA 3.0
2017-09-22T18:33:32.107Z
The way you pose the question suggests that you have doubts yourself. Given that, I don't think it will work. However, an analogy doesn't need to be perfect in every way. If it were an exact match it wouldn't be an analogy, but the real thing. You can use a simple analogy to introduce a topic and get the synapses in the student minds aligned in the right direction. For the deeper case either use a more sophisticated analogy or depend on the fact that they already know something about the topic so analogy is less important.
Buffy
CC BY-SA 3.0
2017-09-25T16:40:29.833Z
I don't think any analogy is going to help. Delegates are conceptually pretty simple. The problem is that the .NET implementation is a bit weird, and no analogy can help with that. The fact that delegates are an abstract concept means that you should be trying to explain _how_ to use them, not how they work. Don't talk about power strips - which are concrete and nothing like delegates - talk about _events_ and _callbacks_ and show them _Linq_. Give them some use cases and let them work out the rest (there is much).
VisualMelon
CC BY-SA 3.0
2017-09-28T22:35:20.940Z
I though about writing an answer, but will rather let my secretary write one for you instead.
Marco13
<lesson-ideas><teaching-analogy><abstraction>
Physical analogy to introduce a Delegate in .Net programming
# Physical analogy to introduce a Delegate in .Net programming

(Asked by: username_0 on 2017-09-22)

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?

**Tags:** lesson-ideas, teaching-analogy, abstraction

> **Comments:**
> **username_1**: The way you pose the question suggests that you have doubts yourself. Given that, I don't think it will work. However, an analogy doesn't need to be perfect in every way. If it were an exact match it wouldn't be an analogy, but the real thing. You can use a simple analogy to introduce a topic and get the synapses in the student minds aligned in the right direction. For the deeper case either use a more sophisticated analogy or depend on the fact that they already know something about the topic so analogy is less important.  
> **username_2**: I don't think any analogy is going to help. Delegates are conceptually pretty simple. The problem is that the .NET implementation is a bit weird, and no analogy can help with that. The fact that delegates are an abstract concept means that you should be trying to explain _how_ to use them, not how they work. Don't talk about power strips - which are concrete and nothing like delegates - talk about _events_ and _callbacks_ and show them _Linq_. Give them some use cases and let them work out the rest (there is much).  
> **username_3**: I though about writing an answer, but will rather let my secretary write one for you instead.  

---

## 4 answers

### Answer by username_4 on 2017-09-26. Score: 1

I know that you are looking for a physical analogy, but I'd say I agree with @username_5 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 by username_5 on 2017-09-22. Score: 0

# 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 by username_6 on 2017-09-23. Score: 0

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 by username_7 on 2017-09-27. Score: -1

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).

> **Comments:**
> **username_7**: It's customary to include a comment when downvoting.  

---

