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