Everyone seems to generally agree that prototype inheritance is simpler and more flexible than class inheritance. What I have not seen in the literature that I\'ve read is very
Ok, I'll add one, use the fact that prototype links are live to monkey-patch methods for a whole class of objects:
var Cat = function(catName) {
this.catName = catName;
};
Cat.prototype.meow = function() {
console.log(this.catName+" says meow");
}
var mittens = new Cat("Mittens");
var whiskers = new Cat("Whiskers");
mittens.meow(); // "Mittens says meow"
whiskers.meow(); // "Whiskers says meow"
// All cats are now angry
Cat.prototype.meow = function() {
console.log(this.catName+" says hissssss");
}
mittens.meow(); // "Mittens says hissssss"
whiskers.meow(); // "Whiskers says hissssss"
This would be useful if you have objects that suddenly need to start acting in a completely different yet consistent manner in response to some sort of global event. Maybe for something like:
I don't think I agree with your premise, but the major benefit of prototype based inheritance is that it allows runtime assignment of properties and methods on all members of the class, even when there are already instances of that class.
The theorist in me actually cringes at some of those implications. Imagine debugging something where you have no idea which piece of code has completely re-defined your class structure. It is beyond daunting.
But, I will say, that it has proven useful:
Once, when I was working in ActionScript 2 (not for the faint of heart as it is almost a non-deterministic language) inside of an ActionScript 3 container. An unknown side-effect of this problem is that it eliminates the idea of memory levels (something essential to my company's legacy code). I was able to add the line: MovieClip.prototype._level0 = _root;
and it solved the problem.
To counter my above argument, the fact that you can modify all instances after the fact does provide you with a certain amount of power in situations where you do not have access to the original code base (like the example), but I see no major benefit beyond that.
One difference (perhaps at least conceptually) is that class inheritance implies that the child IS-A type of the parent. Prototype inheritance makes no such implication; a mammal is a prototype for a cat (the Merriam-Webster definition says this means it's a "pattern for"), but nothing else. A cat is free remove/add/change behaviors as it sees fit.
Since there is no real class inheritance in JavaScript, you will probably never find any literature explaining what you can't do with classic class inheritance in JavaScript, unless you compare it with class inheritance in other languages.
So I'll consider your question as if you meant:
What are some patterns that you can use with JavaScript prototype inheritance that you cannot do with class inheritance in languages that support it?
R= In general, most object oriented languages that are based in Class Inheritance produce objects that have a rigid structure, they will always have the same methods and properties during their life and all the objects of the same classes will have the same structure.
So, in general, the patterns you can apply with a prototype based language that can't be implemented with a class inheritance language are the ones that depend on:
*This is so well supported in JavaScript due to it's dynamic an cross domain collaborative nature. Sometimes you need to load external scripts from other websites but need to add new functionalities without being able to change the source-code from these external libraries.