<p>The sample is <em>not</em> "defining something with itself." Rather it is defining two different kinds of things.</p>

<p>The first line: <code>public class Node&lt;T&gt; {</code> is beginning the definition of a <em>template</em> for things to be made later. That definition will be handled at compile time. The third line: <code>Node&lt;T&gt; next;</code> sets up an <em>object</em> that will be instantiated using some template. Later in the compile process, when the object is created, Java will look in the table for the <em>template</em> called "Node" that can handle some type. Since, by then, the complete template will exist, there's no problem. The key point here is that <code>next</code> is not a <em>template</em>, it is <em>object</em> that <strong>will</strong> use the <code>Node&lt;T&gt;</code> <em>template</em> when it is created.</p>

<p>If you also define <code>public class Node2&lt;T&gt; extends Node&lt;T&gt;</code>, then at run time, <code>next</code> could refer to the <em>template</em> <code>Node&lt;T&gt;</code>, or the <em>template</em> <code>Node2&lt;T&gt;</code>. Exactly which it is will be determined when the <code>next</code> object is instantiated.</p>

<p>If it hasn't already been covered, that would be an opportune time to cover early and late binding.</p>

CC BY-SA 3.0
2017-06-03T09:30:28.390Z
Oh. The template\object explanation is quite good. So I should add a section about what happens when (compile vs runtime) with this example (after the students understand it)?
ItamarG3
CC BY-SA 3.0
2017-06-03T09:32:06.303Z
@ItamarGreen Or, divert into that to help them grasp this. They will need that to grasp polymorphism.
Gypsy Spellweaver
CC BY-SA 3.0
2017-06-03T09:26:07.400Z
2017-06-03T09:26:07.400Z
Gypsy Spellweaver
<h2>Reference</h2>

<p>The existing answers seem to be missing the word "reference".</p>

<p>The problem would be real if that <code>Node&lt;T&gt;</code> attribute were (like in a C++ <code>struct</code>) really a "physical" node, right in there. But it is not - it is just a reference pointing to an actual object somewhere else on the heap. Nothing special about that, the fact that it happens to be the same type as defined currently does not hurt at all since all references are just the same if you look at them closely (i.e., a placeholder).</p>

<h2>Trees</h2>

<p>It may help to introduce the abstract tree data structure, without referencing (sic) any particular programming language.</p>

<h2>Real world</h2>

<p>Also, real world examples are plentiful. Books regularly contain references to other books. Papers contain references to other papers. People know other people (have a "reference" in their brain) without having little people sitting inside their skull. And so on. </p>

CC BY-SA 3.0
2017-06-14T09:56:23.193Z
Those real world examples are very handy. They also fit in well with the lesson plan. Thanks!
ItamarG3
CC BY-SA 3.0
2017-06-14T09:54:13.543Z
2017-06-14T11:10:08.343Z
2017-06-14T11:10:08.343Z
AnoE
<p>A visual demonstration might help. Let's say for the purpose of this in-class demo that the generic <code>T</code> is an object of class <code>Student</code> and you are demonstrating a (singly or doubly) linked list.</p>

<ul>
<li>Have students from a line in front of the class, so they are next to each other and facing the rest of the class. </li>
<li>Explain how each object here is clearly an instance of the <code>Student</code> class. (This should be relatively obvious.)</li>
<li>Now ask the class to brainstorm how this order could be preserved in memory, i.e. how each student could know what other student is to his/her right and left (if there is such a student).</li>
<li>Hopefully students will recognize that they will want to know the name of that student (i.e. that <code>Student</code> object) and thus should store the (one or two) adjacent students' names as <code>Node&lt;T&gt; next</code> (and possibly <code>Node&lt;T&gt; prev</code> if doubly linked).</li>
<li>Model this behavior by having students point to the student on their left with their right arm and the student on their right with their left arm, forming a chain of linked students.</li>
<li>Emphasize at this point that the order is preserved because each object contains within it as a property the name of its neighboring object(s).</li>
</ul>

<p>To extend this example in the context of linked lists, you can insert and remove nodes and see if students can figure out how to preserve order without orphaning part of the list.</p>

CC BY-SA 3.0
2017-06-03T18:00:08.117Z
That will be a very enjoyable lesson for them ;P. Thanks!
ItamarG3
CC BY-SA 3.0
2017-06-03T17:58:02.200Z
2017-06-03T17:58:02.200Z
Peter
<p>In some programming languages, many data structures use <code>Node&lt;T&gt;</code> (The examples in the question are in Java, but I suppose they are similar in other languages):</p>

<pre><code>public class Node&lt;T&gt; {
    T info;
    Node&lt;T&gt; next;
    ...
</code></pre>

<p>I have seen students stare at the board\screen, perplexed, whenever this is introduced. They are confused by this implementation, because it is <em>"Defining something with itself"</em> (like saying "<strong>white</strong> is the color of things that are <strong>white</strong>-hot").</p>

<p>They have difficulty understanding how a class can have a property of itself.
How could I explain to them why this is valid in programming? </p>

<p>This issue makes it hard for them to understand data structures like <code>List</code>,<code>Queue</code> etc.</p>

<p>Context: they are high-school students learning java, and are familiar with primitive types and a bit of OOP.</p>

CC BY-SA 3.0
2017-06-03T16:56:22.180Z
Maybe explain the benefit of writing a class once that is able to handle instances of different types of objects. Start with several types that implements a base object or interface. Write a list that needs to call the base properties or methods, e.g. validating before allowing it to be added, or otherwise throw an exception. Maybe the penny will drop. I'm assuming they have some grasp OOP principles.
Dave Russell
CC BY-SA 3.0
2017-06-03T17:00:52.613Z
@JTC The problem isn't with the generics of `T`, it's the `Node` field of the `Node` class which is difficult for the students.
ItamarG3
CC BY-SA 3.0
2017-06-03T17:07:49.540Z
I know, i admit I'm not directly answering your question :(. I was giving an example to build them up to understanding.
Dave Russell
CC BY-SA 3.0
2017-06-03T17:17:04.787Z
@JTC Oh. Well it's more than welcome
ItamarG3
<object-oriented-paradigm><data-structure>
Introducing self containing objects (Node)
# Introducing self containing objects (Node)

(Asked by: username_0 on 2017-06-03)

In some programming languages, many data structures use Node (The examples in the question are in Java, but I suppose they are similar in other languages):
public class Node {
    T info;
    Node next;
    ...

I have seen students stare at the board\screen, perplexed, whenever this is introduced. They are confused by this implementation, because it is "Defining something with itself" (like saying "white is the color of things that are white-hot").
They have difficulty understanding how a class can have a property of itself.
How could I explain to them why this is valid in programming? 
This issue makes it hard for them to understand data structures like List,Queue etc.
Context: they are high-school students learning java, and are familiar with primitive types and a bit of OOP.

**Tags:** object-oriented-paradigm, data-structure

> **Comments:**
> **username_1**: Maybe explain the benefit of writing a class once that is able to handle instances of different types of objects. Start with several types that implements a base object or interface. Write a list that needs to call the base properties or methods, e.g. validating before allowing it to be added, or otherwise throw an exception. Maybe the penny will drop. I'm assuming they have some grasp OOP principles.  
> **username_0**: @JTC The problem isn't with the generics of `T`, it's the `Node` field of the `Node` class which is difficult for the students.  
> **username_1**: I know, i admit I'm not directly answering your question :(. I was giving an example to build them up to understanding.  
> **username_0**: @JTC Oh. Well it's more than welcome  

---

## 3 answers

### Answer by username_4 on 2017-06-03. Score: 2 | Accepted answer

A visual demonstration might help. Let's say for the purpose of this in-class demo that the generic `T` is an object of class `Student` and you are demonstrating a (singly or doubly) linked list.

* Have students from a line in front of the class, so they are next to each other and facing the rest of the class.
* Explain how each object here is clearly an instance of the `Student` class. (This should be relatively obvious.)
* Now ask the class to brainstorm how this order could be preserved in memory, i.e. how each student could know what other student is to his/her right and left (if there is such a student).
* Hopefully students will recognize that they will want to know the name of that student (i.e. that `Student` object) and thus should store the (one or two) adjacent students' names as `Node next` (and possibly `Node prev` if doubly linked).
* Model this behavior by having students point to the student on their left with their right arm and the student on their right with their left arm, forming a chain of linked students.
* Emphasize at this point that the order is preserved because each object contains within it as a property the name of its neighboring object(s).

To extend this example in the context of linked lists, you can insert and remove nodes and see if students can figure out how to preserve order without orphaning part of the list.

> **Comments:**
> **username_0**: That will be a very enjoyable lesson for them ;P. Thanks!  

---

### Answer by username_2 on 2017-06-03. Score: 2

The sample is *not* "defining something with itself." Rather it is defining two different kinds of things.

The first line: `public class Node {` is beginning the definition of a *template* for things to be made later. That definition will be handled at compile time. The third line: `Node next;` sets up an *object* that will be instantiated using some template. Later in the compile process, when the object is created, Java will look in the table for the *template* called "Node" that can handle some type. Since, by then, the complete template will exist, there's no problem. The key point here is that `next` is not a *template*, it is *object* that **will** use the `Node` *template* when it is created.

If you also define `public class Node2 extends Node`, then at run time, `next` could refer to the *template* `Node`, or the *template* `Node2`. Exactly which it is will be determined when the `next` object is instantiated.

If it hasn't already been covered, that would be an opportune time to cover early and late binding.

> **Comments:**
> **username_0**: Oh. The template\object explanation is quite good. So I should add a section about what happens when (compile vs runtime) with this example (after the students understand it)?  
> **username_2**: @ItamarGreen Or, divert into that to help them grasp this. They will need that to grasp polymorphism.  

---

### Answer by username_3 on 2017-06-14. Score: 2

## Reference

The existing answers seem to be missing the word "reference".

The problem would be real if that `Node` attribute were (like in a C++ `struct`) really a "physical" node, right in there. But it is not - it is just a reference pointing to an actual object somewhere else on the heap. Nothing special about that, the fact that it happens to be the same type as defined currently does not hurt at all since all references are just the same if you look at them closely (i.e., a placeholder).

## Trees

It may help to introduce the abstract tree data structure, without referencing (sic) any particular programming language.

## Real world

Also, real world examples are plentiful. Books regularly contain references to other books. Papers contain references to other papers. People know other people (have a "reference" in their brain) without having little people sitting inside their skull. And so on.

> **Comments:**
> **username_0**: Those real world examples are very handy. They also fit in well with the lesson plan. Thanks!  

---

