Analogy for static objects (or members)

Question

I'm trying to think of an analogy to explain how static members, references and objects work.

What I have in mind is saying that static is like the number of computers in the world. That parameter isn't related to any specific computer, but rather to Computer in general.

However I feel like this might confuse students, partly due to the name static (i.e. something that doesn't move).

Can anyone suggest an analogy that shows what static means in everyday things? Preferably something that high-school students can relate to and understand.

Answer 1

Static members belong to the type, not the instance

Static members are best seen as belonging to the type rather than the instance. If you're inside a class, it can be harder to see:

class Animal
{
    static int moveSpeed = 4;
    int currentLocation = 10;

    void Walk()
    {
        //  Can you tell which variable is static without looking above?
        currentLocation += moveSpeed;
    }
}

But it's easier to see in an external scope where the member needs to be called:

void Foo()
{
    var animal = new Animal();

    var x1 = animal.moveSpeed;       //  Invalid - .moveSpeed belongs to the type, not a specific animal
    var x2 = animal.currentLocation; //  Valid
    var x3 = Animal.moveSpeed;       //  Valid
    var x4 = Animal.currentLocation; //  Invalid - the type Animal doesn't have some common value for currentLocation
}

See static members through the compiler's eyes

In languages like C#/Java, the compiler makes all methods static during the compilation process. Instance methods get an extra argument added to their method signature that specifies this:

class Animal
{
    //  In source code, as before:
    void Walk()
    {
        currentLocation += moveSpeed;
    }

    //  More explicit source code:
    void Walk()
    {
        this.currentLocation += Animal.moveSpeed;
    }

    //  How the compiler sees it:
    static void Walk(Animal this)
    {
        this.currentLocation += Animal.moveSpeed;
    }
}

Analogies

Since static methods are those that don't vary with an instance, you can compare them to personal qualities about people vs. impersonal qualities.

For example, when students hand in a math test, if the answer to a problem is $5$, then that's the correct answer for all students. But, Bob should write "Bob" on his exam, while Sally should write "Sally" on her exam - that varies with the instance of the student.

static relativity

Analogies can get tricky because static-ness is relative. This isn't easy to reproduce in simple type systems like used in Java/C#, but it's apparent in languages with more meta-programming features, e.g. Ruby, where a type is itself an instance of another type.

For an analogy, consider a class Dog. You might say that all Dog's have .Legs = 4;, but that they can have differing .Weights. From this perspective, .Legs is static.

But, Dog can itself be an instance of a class, Animal. From the perspective of Animal, .Legs isn't static, but rather varies with the instances of Animal - and the instance called Dog just happens to have .Legs=4;, but the instance called Human has .Legs=2;.

Static relativity won't make sense if students are just learning Java/C#-like type systems, but some students might ask questions that bring it up anyway. For example, if you give .Legs as an example, students might ask how to handle a more general type where .Legs can vary - this can be explained through a meta-class structure.

Answer 2

I use school colors and principal's name.

If someone comes in tomorrow and says your principal is no longer Mr. Smith, it's now Ms. Jones then that change is made for every object (student) in the school. You don't have to go to each individual student and tell them that their principal has changed.

It worked really well this year because we did get a new principal.

Answer 3

One way to approach this might be to have students identify what they all have in common and what they each possess individually. That which is common -- like the school they are attending or the class (and maybe grade level) they are in -- should be static. That which is not -- like name or age -- should not be static.

You could also go into sufficient and necessary conditions. For example, a necessary condition for something being a bicycle is having two wheels, but it's not sufficient because you could have a two-wheeled motorcycle. To model a class Bicycle, you could make its necessary conditions into static variables, such as static int numWheels.

Answer 4

An example of static, "preferably something that high-school students can relate to and understand", would be the instructor. Each period for the Computer class has different students, different times, maybe different assignments (to prevent cheating) but the instructor stays the same. It's still a member, since the English class has a different instructor (also static to the English class, of course).

Side benefit: you can also use the keyword class.

Answer 5

Here's an answer that will not make you happy. If you need an analogy, maybe the concept is too complex to be taught? The literature on CS education does not show a lot of support for analogical teaching; in fact, analogies often get in the way and create as much confusion as they help. People have pointed to the need to have clear and crisp notional machines instead. If your notional machine doesn't include static members, you should enhance it so it does; because if it continues to not include them, then no amount of analogical reasoning is going to get students unstuck when they come to reading, tracing, and debugging programs.

So the real question is, what does your notional machine say about static members?

Answer 6

Building upon the animal classification analogy for OOP in general, if you consider felines as a whole to be a class, then a static member could be family = "Felidae".

Answer 7

Historically, the word 'static' was chosen to indicate something "statically typed" or defined, that is: known at compile time, in contrast to 'dynamic' - known at run-time.

The word is a bit obscure these days, but with that explanation, they will understand the real point - known at compile time. Relate it to the word 'stationary' - not going anywhere - which has the same root.