<p>Here's an answer that will not make you happy. If you need an <em>analogy</em>, 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 <em>notional machines</em> 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.</p>

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

CC BY-SA 3.0
2017-06-03T11:42:41.007Z
Well, you could always Google for it (-:. See, for instance, this detailed [blog post](https://computinged.wordpress.com/2012/05/24/defining-what-does-it-mean-to-understand-computing/).
Shriram Krishnamurthi
CC BY-SA 3.0
2017-06-03T05:29:01.023Z
Not Sure I understand what `notional machine` means... could you explain
ItamarG3
CC BY-SA 4.0
2018-05-15T13:58:15.530Z
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.
CC BY-SA 4.0
2018-05-15T18:15:24.940Z
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
CC BY-SA 3.0
2017-06-03T00:29:16.433Z
2017-06-03T00:29:16.433Z
Shriram Krishnamurthi
<p>Building upon the <a href="https://cseducators.stackexchange.com/a/152/166">animal classification analogy</a> for OOP in general, if you consider felines as a whole to be a class, then a static member could be <code>family = "Felidae"</code>.</p>

CC BY-SA 3.0
2017-05-28T18:14:55.507Z
I see what you're talking about, but that isn't about `static` or not.
ItamarG3
CC BY-SA 3.0
2017-05-28T17:26:06.623Z
2017-05-28T17:26:06.623Z
Scimonster
<h3>Static members belong to the type, not the instance</h3>

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

<pre><code>class Animal
{
    static int moveSpeed = 4;
    int currentLocation = 10;

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

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

<pre><code>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
}
</code></pre>

<h3>See <code>static</code> members through the compiler's eyes</h3>

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

<pre><code>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;
    }
}
</code></pre>

<h3>Analogies</h3>

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

<p>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.  <em>But</em>, Bob should write "Bob" on his exam, while Sally should write "Sally" on her exam - that varies with the instance of the student.</p>

<h3><code>static</code> relativity</h3>

<p>Analogies can get tricky because <code>static</code>-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.</p>

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

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

<p>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 <code>.Legs</code> as an example, students might ask how to handle a more general type where <code>.Legs</code> can vary - this can be explained through a meta-class structure.</p>

CC BY-SA 3.0
2017-12-06T21:57:11.213Z
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
CC BY-SA 3.0
2017-12-06T22:00:04.823Z
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
CC BY-SA 3.0
2017-05-29T10:25:16.320Z
2017-06-01T13:57:40.390Z
2017-06-01T13:57:40.390Z
Nat
<p>I use school colors and principal's name. </p>

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

<p>It worked really well this year because we did get a new principal. </p>

CC BY-SA 3.0
2017-05-29T07:10:20.270Z
Aw shoot! Then I should have used that 2 years ago. Well it's still applicable. Thanks!
ItamarG3
CC BY-SA 3.0
2017-05-28T22:32:43.613Z
2017-05-28T22:32:43.613Z
Ryan Nutt
<p>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 <code>static</code>. That which is not -- like name or age -- should not be static. </p>

<p>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 <code>Bicycle</code>, you could make its necessary conditions into static variables, such as <code>static int numWheels</code>.  </p>

CC BY-SA 3.0
2017-05-28T18:13:52.683Z
I like the necessary-sufficient idea. Thanks!
ItamarG3
CC BY-SA 3.0
2017-05-28T18:12:10.620Z
2017-05-28T18:12:10.620Z
Peter
<p>An example of <code>static</code>, "preferably something that high-school students can relate to and understand", would be the instructor. Each period for the <code>Computer</code> 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 <code>English</code> class has a different instructor (also <code>static</code> to the <code>English</code> class, of course).</p>

<p>Side benefit: you can also use the keyword <code>class</code>.</p>

CC BY-SA 3.0
2017-05-30T10:34:10.203Z
2017-05-30T10:53:05.670Z
2017-05-30T10:53:05.670Z
Gypsy Spellweaver
<p>I'm trying to think of an analogy to explain how static members, references and objects work. </p>

<p>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 <strong>specific</strong> computer, but rather to Computer in general. </p>

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

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

CC BY-SA 3.0
2017-05-28T18:56:46.593Z
This question makes me wish I could upvote multiple times.
Ben I.
CC BY-SA 3.0
2017-05-28T22:39:38.903Z
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
CC BY-SA 3.0
2017-05-28T23:08:14.557Z
You should tag this question with a language for specificity's sake.
Ben I.
<java><teaching-analogy><secondary-education><static>
Analogy for static objects (or members)
# Analogy for static objects (or members)

(Asked by: username_0 on 2017-05-28)

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.

**Tags:** java, teaching-analogy, secondary-education, static

> **Comments:**
> **username_1**: This question makes me wish I could upvote multiple times.  
> **username_2**: 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).  
> **username_1**: You should tag this question with a language for specificity's sake.  

---

## 6 answers

### Answer by username_5 on 2017-05-29. Score: 6 | Accepted answer

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.

> **Comments:**
> **username_6**: 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)  
> **username_6**: 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.  

---

### Answer by username_7 on 2017-05-28. Score: 6

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.

> **Comments:**
> **username_0**: Aw shoot! Then I should have used that 2 years ago. Well it's still applicable. Thanks!  

---

### Answer by username_8 on 2017-05-28. Score: 5

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

> **Comments:**
> **username_0**: I like the necessary-sufficient idea. Thanks!  

---

### Answer by username_9 on 2017-05-30. Score: 3

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 by username_3 on 2017-06-03. Score: 1

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?

> **Comments:**
> **username_0**: Not Sure I understand what `notional machine` means... could you explain  
> **username_3**: Well, you could always Google for it (-:. See, for instance, this detailed [blog post](https://computinged.wordpress.com/2012/05/24/defining-what-does-it-mean-to-understand-computing/).  
> **username_1**: 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".  
> **username_3**: 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.  

---

### Answer by username_4 on 2017-05-28. Score: 0

Building upon the [animal classification analogy](https://cseducators.stackexchange.com/a/152/166) for OOP in general, if you consider felines as a whole to be a class, then a static member could be `family = "Felidae"`.

> **Comments:**
> **username_0**: I see what you're talking about, but that isn't about `static` or not.  

---

