How prototypal inheritance is practically different from classical inheritance?

Question

Inheritance, Polymorphism, and Encapsulation are the three most distinct, important features of OOP, and from them, inheritance has a high usage statistics these days. I'm learning JavaScript, and here, they all say that it has prototypal inheritance, and people everywhere say that it's something far different from classical inheritance.

However, I can't understand what's their difference from the point of practical usage? In other words, when you define a base class (prototype) and then derive some subclasses from it, you both have access to functionalites of your base class, and you can augment functions on the derived classes. If we consider what I said to be the intended result of inheritance, then why should we care if we're using prototypal or classic version?

To clear myself more, I see no difference in the usefulness and usage patterns of prototypal and classic inheritance. This results in me having no interest to learn why they are different, as they both result in the same thing, OOAD. How practically (not theoretically) prototypal inheritance is different from classical inheritance?

Answer 1

Recent blog post about JS OO

I believe what your comparing is classical OO emulation in JavaScript and classical OO and of course you can't see any difference.

Disclaimer: replace all references to "prototypal OO" with "prototypal OO in JavaScript". I don't know the specifics of Self or any other implementation.

However prototypal OO is different. With prototypes you only have objects and you can only inject objects into other objects prototype chain. Whenever you access a property on an object you search that object and any objects in the prototype chain.

For prototypal OO there is no notion of encapsulation. Encapsulation is a feature of scope, closures and first class functions but has nothing to do with prototypal OO. There is also no notion of inheritance, what people call "inheritance" is actually just polymorphism.

It does however have polymorphism.

For example

var Dog = {
  walk: function() { console.log("walks"); }
}

var d = Object.create(Dog);
d.walk();

Clearly d has access to the method Dog.walk and this exhibits polymorphism.

So actually there is a big difference. You only have polymorphism.

However as mentioned, if you desired to do so (I have no idea why you would) you can emulate classical OO in JavaScript and have access to (restricted) encapsulation and inheritance.

Answer 2

Classical inheritance inherits the behavior, without any state, from the parent class. It inherits the behavior at the moment the object is instantiated.

Prototypal inheritance inherits behavior and state from the parent object. It inherits the behavior and state at the moment the object is called. When the parent object changes at run-time, the state and behavior of the child objects are affected.

The "advantage" of prototypal inheritance is that you can "patch" state and behavior after all your objects are instantiated. For example, in the Ext JS framework it's common to load "overrides" that patch the framework's core components after the framework has been instantiated.

Answer 3

First: Most of the time, you'll be using objects, not defining them, and using objects is the same under both paradigms.

Second: Most prototypal environments use the same kind of division as class based environments -- mutable data on the instance, with methods inherited. So there's very little difference again. (See my answer to this stack overflow question, and the Self Paper Organizing Programs Without Classes. Look at Citeseer for a PDF version.)

Third: Javascript's dynamic nature has a much bigger influence that the kind of inheritance. The fact that I can add a new method to all instances of a type by assigning it to the base object is neat, but I can do the same thing in Ruby, by reopening the class.

Fourth: The practical differences are small, while the practical issue of forgetting to use new is much bigger -- that is, you're far more likely to be affected by missing a new than you are to be affected by the difference between prototypal and classical code.

All that said, the practical difference between prototypal and classical inheritance is that your things-that-hold-methods (classes) are the same as your things-that-hold-data (instances.) This means that you can build up your classes piecemeal, using all the same object manipulation tools that you would use on any instance. (This is, in fact, how all of the class-emulation libraries do it. For a not-quite-like-all-the-others approach, look at Traits.js). This is primarily interesting if you are metaprogramming.

Answer 4

Prototypal inheritance in JavaScript is different from classes in these important ways:

Constructors are simply functions that you can call without new:

function Circle (r, x, y) { 
  //stuff here
}
Var c = new Circle();
Circle.call(c, x, y, z); //This works and you can do it over and over again.

There are no private variables or methods, at best you can do this:

function Circle (r, x, y) {
  var color = 'red';
  function drawCircle () {
    //some code here with x, y and r
  }
  drawCircle();
  this.setX = function (x_) {
    x = x_;
    drawCircle();
  }

}
Circle.prototype.getX = function () {
   //Can't access x!
}

In the previous example you can't extend the class meaningfully if you're resorted to fake private variables and methods and in addition any public methods you've declared will be recreated every time a new instance is created.