1

For the past week I've been trying to understand the difference between class based and prototypical inheritance. Having worked with PHP and JavaScript, I expected to grasp this rather quickly, but I just can't wrap my head around this – I always have the feeling that I miss something.

I've learned that a class is like a blueprint defining an object's characteristics. When a class is instantiated, an object is constructed according to the blueprint. When inheritance comes into play, the blueprint can only be adopted completely but methods can be overridden.

But what is a prototype then? Isn't it also like a blueprint, but already implemented (hence the name "prototype")? So with inheritance, you can only point to already existing functions?

The following may seem silly but thats the way I try to understand things.

In more human terms: A class can be regarded as architectural plan, as soon as it get's instantiated small workers start building an object according to that plan. To inherit something, the complete plan is built again, in addition to new details (that may replace existing details).

With prototypes, the workers instead start copying an already existing object and start looking at it's main characteristics (stored on something called the prototype). To inherit from another object, they just put a sign somewhere saying "You are looking for function X? Please this way – mind the gap between objects".

Is this distinction correct?

Sven
  • 12,997
  • 27
  • 90
  • 148
  • 2
    [classical inheritance vs protoypal inheritance in javascript](http://stackoverflow.com/questions/19633762/classical-inheritance-vs-protoypal-inheritance-in-javascript) – Tushar Apr 09 '16 at 14:51
  • https://stackoverflow.com/questions/34707632/difference-between-classical-inheritance-and-prototype-inheritance – Bergi Apr 12 '16 at 09:39
  • Actually, in prototypal inheritance the workers don't copy anything - they just put up the sign. – Bergi Apr 12 '16 at 09:43

1 Answers1

10

It seems to me that you actually already got the point.

Class based OO

As you already mentioned, in class-based object oriented languages (like Java) a class is a blueprint for every future object. For the instantiation of an object the blueprint (the class you created) gets copied for this object. This means that in case you change the class after you instantiate your object the previously created object won't have that changes.

When it comes to inheritance: Let's say you have a class Person. You want to create another class Student that inherits from Person. Student is basically a copy of the blueprint Person which can extend the functionality of the blueprint. So your example is very accurate! This is very useful in complex but rather static OO-structures!

Prototype based

Prototype based languages like JavaScript don't follow this templating kind of approach. Your example hit it pretty good again. You basically just create an object and reference to another object (your prototype). All the functionality you put in your prototype will be shared by all the objects that reference to that prototype object. However, it is important to understand that you don't make copies of blueprints or templates. You are always working with objects.

So you could create a Person Object. That holdsmethods like "sayHello". If you create concrete person e.g. Joe you just create another object and link it to the Person object. So if you try Joe.sayHello() it will look through the Joe object properties and won't find the sayHello method so it will jump over to the concrete Person object. Just like you said with your example.

I don't really like the expression inheritance in prototype based languages because it does not really exist. You don't make a copy of a blueprint and extend its functionality. Inheritance basically works by chaining objects together. For instance the example above. You can have a Person object. Every regular person object (e.g. Joe) has the Person Object as a prototype. Now you create a Student object which has the Person as a prototype. Another object (e.g. StudentJoe) can have Student as a prototype. So it can go through the chain all the way up to person to access its methods. To keep it short ;): prototype based languages only work with concrete objects which are linked together (prototypes) and not with blue prints and templates. The advantage of this approach is being dynamic (that's why this approach is commonly used in the web). As you never work with templates but with concrete objects every change in the prototype-chain will always have effect on every object (in terms of accessable functionality) - no matter when it was created.

I hope this helped. There is a good book called You don't know JavaScript - this & object prototype which explains this topic based on JavaScript really well.

Clemens Paumgarten
  • 151
  • 1
  • 9
  • This helped indeed! Thank you, I am now much more confident with this then I was before. – Sven Apr 12 '16 at 19:11
  • 1
    This explanation stands out, among countless blog posts, articles and Q&As, which mostly dodge the question of what the difference actually is. Thank you. – Magnus Jan 29 '18 at 22:39