# Analogy for static objects (or members)

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.

• This question makes me wish I could upvote multiple times. – Ben I. May 28 '17 at 18:56
• The static keyword was re-used in C++ for this usage, to avoid introducing another keyword. How did you explain void, public, main? All of these have no good meaning in lesson1, and can only be explained about ½way through the course. In Eiffel it does not have these words, there is no main, there are reasonable defaults of access, if you don't return a value than don't declare a return type, and there is no such thing as static, you don't need it (the only use for it is once methods, eiffel has these. All other uses are harmful). – ctrl-alt-delor May 28 '17 at 22:39
• You should tag this question with a language for specificity's sake. – Ben I. May 28 '17 at 23:08

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

• I feel this answer could be improved by expanding on the "belongs to the type" notion by making it clearer that it is "shared" by all instances of the class (where changing it affects all classes (and sub-classes)). For example, if all cars make a "honk" noise, then that could be modelled as public static String noise = "honk"; (or perhaps as a static makeNoise() method. If you were to be providing sound-effects over a silent movie, then it would be inefficient to have a separate "honker" per car - instead you'd have one for all cars (i.e. make it static, therefore shared, by all cars) – kwah Dec 6 '17 at 21:57
• Of course, whether it is appropriate for "whatever-is-being-made-static" to be shared is another question is a topic of later when looking at proper design and design-patterns. – kwah Dec 6 '17 at 22:00

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.

• Aw shoot! Then I should have used that 2 years ago. Well it's still applicable. Thanks! – ItamarG3 May 29 '17 at 7:10

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.

• I like the necessary-sufficient idea. Thanks! – ItamarG3 May 28 '17 at 18:13

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.

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?

• Not Sure I understand what notional machine means... could you explain – ItamarG3 Jun 3 '17 at 5:29
• Well, you could always Google for it (-:. See, for instance, this detailed blog post. – Shriram Krishnamurthi Jun 3 '17 at 11:42
• OMG - notional machine - this is what I have been looking for! Analogies, begone! – user737 Jul 7 '17 at 14:57
• This isn't right. A notational machine is, itself, an analogy for a similar, more realistic process. The famous, oft-(over)stated danger of analogies should really only be considered the danger of poor analogies. I would argue instead that connecting new ideas to older, already encoded ideas (a literal, physical manifestation of analogy) is the most basic mechanism of how we learn. Great analogies are not at all an indication that something is "too complex to be taught". – Ben I. May 15 '18 at 13:58
• A notional machine is not an analogy. It's a faithful representation at some human-comprehensible level of abstraction. It should at least be sound, if not complete. Analogies, by definition, are going to be unsound at some level. – Shriram Krishnamurthi May 15 '18 at 18:15

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

• I see what you're talking about, but that isn't about static or not. – ItamarG3 May 28 '17 at 18:14

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.