Teaching References in C#

In a couple of weeks, I'll be teaching a class of first-year engineers the salient points of references 开发者_C百科in C# as part of their first-year programming course. Most of them have never programmed before, and had enough trouble learning objects, so teaching references is going to be an uphill battle. I plan to have lots of examples available for the students to go through on their own, but just showing a bunch of examples tends to be pretty overwhelming if the the underlying concept doesn't 'click'.

So I'll put the question out to the SO community: what's the best way you've seen references taught? What made it 'click' for you? Is there any reference-related material that I'm missing?

My tentative lesson plan is:

1. What is a reference (using an argument like Eric Lippert's)
2. References and the Garbage Collector
3. Reference Types and Value Types
4. Immutable Types
5. Passing by Reference versus Passing by Value (and all of the subtleties of object references being passed by value)
6. A handful of nasty examples that produce unexpected results if you don't understand 1-5.

One way that I've heard it explained is to use a cell phone or walkie-talkie. You (the instructor) hold one end and declare that you are an object instance. You stay in one place (ie. the heap) while the students pass the other end (which is on speaker phone if it's a cell phone) around the classroom.

They can interact with you through the "reference" they have to you, but they don't really have "you" in their possession.

Binky! (or @ http://cslibrary.stanford.edu/104/)

I like the URL analogy that describes the differences between Reference and Value types. You can pass around a URL as a reference to some content. You can modify that URL without modifying that content. You can also get to the content via the URL to perhaps modify the content.

This is a useful reference:

 http://www.yoda.arachsys.com/csharp/parameters.html

Try to explain references with figures, as pure text sometimes don't get through to most people. Many resources and books on the topic, do try to explain through figures as it is difficult to relate allocation through verbal communication alone (this is mostly an issue of attention span for most people).

At least try to point out how objects relate to each other, a simple example would be a simple reference.

Given:

class A {
    B b = new B();
}

class B {
   int mine = 1;
}

When instantiating class A as object a from some context the following figure will illustrate how it will all look in the heap. The point of the illustration is to show how the different objects relate to each other and have a mental model for how the heap works.

         +-A-----+
a: *---->|       |
         |       |   +-B--------+
         | b: *--+-->|          |
         |       |   | mine: 1  |
         +-------+   |          |
                     +----------+

Also try to explain the difference between heap and stack allocation. Calling a method with parameters. Simple example would be something like this:

Given the following method:

public void doSomething(B b) {
   int doMine = b.mine + 1;
}

When calling doSomething and letting it do it's stuff, at the end doSomething's stack will look something like below. The point showing that objects do not directly reside inside a stack, but it is just referred to an object in the heap and objects are shared through references.

whoever called doSomething *
                           |
                           v
+-doSomething-+   +-B--------+
| b: *--------+-->|          |
|-------------|   | mine: 1  |
| doMine: 2   |   +----------+
+-------------+

Another illustrative example would be illustrating an array which is an object, and a multidimensional array contains an array of arrays.

I found this article really useful for explaning parameter passing in C#. The article also does a good job explaining value and reference types in general terms.

It's more of a visual representation which helped me a lot.

Pictures and diagrams.

People form mental images of the concepts they're learning, and a visual representation of references and their relation to their associated objects is a good way to start. Likewise, visualizing object as containing member variables (which includes references to other objects) and member methods, a la UML diagrams, is very helpful.

Later, you can delve into the details of how references and primitive types are actually implemented, if you feel the need to do so. But delay these discussions as long as possible, as people can get bogged down in trying to pair abstract concepts to the representational details, which distracts from learning the abstract concepts.

When I was learning VB6, references actually confused me a bit. Then I tried learning C++, and after dealing with pointers, references made perfect sense to me. Understanding it from a what-is-actually-happening perspective was easier to me than understanding it from an oo-concepts perspective. Maybe you can go over the under-the-hood stuff in your lesson.

I would suggest minimizing one's use of the bare term "reference" altogether, since it can be used in .net to refer to two very different things: the content of class-type storage locations, and parameters passed with a "ref" qualifier. Use the term "object reference" for the former, and "ref parameter" for the latter.

In describing what an "object reference" is, I would suggest using the term "object ID". Object ID's have a few things that make them different from "addresses":

1. One can't do very many things with object ID's. One can test whether one is blank, check whether two of them are equal, copy one to a storage location of suitable type, or look up the object referred to by one and ask it to do something. Most requests to do something with a class-type value or variable are really requests to do something with the referred-to object. Note that one cannot manipulate an ID of one object in such a way as to get the ID of another, as one can do with addresses.
2. While the system must have a means of converting object ID's to addresses, there is no guarantee that it will use any particular means of doing so. Nor is there any guarantee that the bit pattern associated with any object ID won't spontaneously change; all that is guaranteed is that if the bit pattern changes, the new pattern will refer to the same object as the old.
3. The system keeps track of every place that object ID's are stored. As long as any copy of an Object ID exists, that object ID will never refer to anything other than the object instance for which it was created. By contrast, in general, systems that use addresses for things do not track every single place where an address might be copied. It's possible that an object might cease to exist while somebody still has a copy of its address, and some new object might be created with the same address.