Blueprints versus finger-pointing

Let's start by looking at how typical object-oriented languages actually create objects.

We are going to talk about an object called myCar. The myCar object is our bits-and-bytes representation of an incredibly simplified real world car. It could have attributes like color and weight, and methods like drive and honk.

In a real application, myCar could be used to represent the car in a racing game – but we are going to completely ignore the context of this object, because we will talk about the nature and usage of this object in a more abstract way.

If you would want to use this myCar object in, say, Java, you need to define the blueprint of this specific object first – this is what Java and most other object-oriented languages call a class.

If you want to create the object myCar, you tell Java to build a new object after the specification that is laid out in the class Car.

The newly built object shares certain aspects with its blueprint. If you call the method honk on your object, like so:

 myCar.honk();

Then the Java VM will go to the class of myCar and look up which code it actually needs to execute, which is defined in the honk method of class Car.

Ok, nothing shockingly new here. Enter JavaScript.