One blueprint, many objects

With objects you can now hold one person's data. So what about ten people's? You end up writing { name: ..., age: ... } ten times. Want one more field and you are adding it in all ten places.

A class is the machinery that gets rid of that repetition. You write a blueprint once — "make things that hold these fields" — and then make as many real ones from it as you like. Fix the blueprint and everything made from it follows.

The blueprint is the class, and a real thing made from it is called an instance. Think of it as a waffle iron and the waffles that come out of it. One iron, any number of waffles. Whatever the filling, the shape is the same.

What settles the contents as you make one is the constructor. Write new Person("Yui", 15) and the constructor gets called, putting the values you handed over into that instance. This is where this shows up, pointing at "this very real thing, the one being made right now". this.name = name means "into the field called name on this real thing, put the value I caught". this is standoffish at first, but read it as "myself" and it gets much easier.

Next come methods. Functions written inside the class, doing something with that instance's data. This is the real value of a class: the data, and the work that handles that data, gather in one place. A person's information and the things you want to do to a person do not drift apart.

The second half of the chapter is inheritance, the machinery for basing a slightly different class on one you already have. There is an "animal" class, and you make a "dog" class from it. You do not rewrite the shared parts, only add the ones that differ. extends takes it over, and super calls the original class's work. Write a method of the same name and you can override the original behaviour.

A class is also the sum of everything the chapters so far taught you. You cannot put one together without variables, functions and objects; and once you do have those, you can see that a class is only those things with "rules for gathering them" added.

Inheritance has an overuse trap in it, too. It is safest used only where you can say "an A is a kind of B" and mean it. "A dog is a kind of animal" holds up; join two things because "they happen to have similar work in them" and fixing one starts breaking the other. Inheritance is not a tool for sharing code, it is a tool for expressing a relationship — keep that in mind.

The thing you are most likely to stumble on in this chapter is, again, this. The same this points at different things depending on where you wrote it. Inside a constructor it means "the real thing being made right now"; inside a method, "the real thing that called that method". When you get muddled, say out loud whose business you are talking about.

One more thing that matters: do not confuse the class with the instance. A class is a mould; there are no concrete values in it. Values live in the real thing you made with new. Mix those two up and you can spend a long time wondering "why can't I get the value out".

As you work through the chapter, try writing the blueprint on paper or in a note first. Put "what fields does this class hold" and "what can it do" into words before you drop it into code. Start writing straight away and you tend to notice halfway that a field is missing, and rewrite it several times.

One note: plenty of real development is written without classes. Even so, they certainly turn up in other people's code, and the idea itself — gathering data and work into one thing — carries over into designs that use no classes at all. There is plenty of point in being able to read them.