In classical programming languages, prototype pattern is used when you don’t want to subclass your class to achieve the wanted behaviour, therefore saving your memory resources and allowing your code more flexibility. In Javascript, you get that pattern for free 🙂 As Js is a prototyped based language, there are no classes (i am not counting ES6 class because it is basically just sugar on prototype inheritance). Take a look at the php docs example to see how the object is “cloned” and made available in another one.

But this is Javascript, and the only inheritance here is prototypal inheritance. and the way this works is that every object you create has a hidden property called the prototype, pointing to another object. As you have probably heard before, everything is an object in Javascript. Well not everything, you still have your strings, ints, bools, nulls and undefineds (also Sets, Maps and Symbols in es6). But to confirm my claim, even the null type thinks it’s an object (typeof null === object). Just kidding, null is just silly reporting that… As i was saying, when you want to access a property of an object, first the objects own properties are looked up, if no match is found, the lookup will continue on the prototype property object, if no match there, it’s prototype will follow. Every object you create has an Object type as its prototype, and the Object type has null as its prototype… I hope i have made this clear enough, if not, here is a neat discussion on stackoverflow complicating things a bit further 😉

So basically, you have many options available when you create your inheritance (prototype) chain.

The most basic example would be this:

Now all the properties of Beverage will be available on the Beer object when we create it, but there are more interesting approaches to this.

Meet the Rent a constructor pattern:

You are probably wondering why the normative prop is undefined, and before i finish this sentence, you already looked at the code above and realized that we are no calling new on the Parent, therefore not triggering the Js prototype mechanism of object creation.

Here, there is no prototype inheritance, as the prototype chain is broken… We are simply appending properties defined in the Beverage to the Beer’s this object.

This way, we can achieve Multiple Inheritance by simply borrowing constructors.

But now, all of our methods and properties get copied to every new created object, there is no prototype involved. Lets fix this using the Rent and set prototype pattern:

Now we have all the constructor methods and props on our object, and all its prototype methods on our prototype. Sweet! If you wanted you could only just Share the Prototype.

Now all the methods that live on our beverage object, will be shared across all Beer and Whiskey instances. But beware, if you change the property on beverage object, all the Beers and Whiskeys (instances) will feel it.

Rent a constructor is also a great pattern, that comes very useful if you have massive inheritance/prototype chains and want your prototypes to be nice and tidy.

Here we used a temporary constructor to be sure that if you decide to add a method that needs to be shared across all the beers, nothing else inheriting from Beverage gets affected.

And now,  lets see the Holy Grail of inheritance

Here we added the uber property on our child, to reference the parents prototype directly (as super is reserved), and also we are setting our prototype.constructor property to our constructor because all the children will report the parent as their constructor. This is the most robust way to achieve inheritance in JS, and having an utility function like this in your codebase can come really handy.

The thing you should realize at the end of this article, is that there is no one way to do inheritance in javascript, nor there should be. ES5 brought us the Object.create method as the way to go when setting prototypes. You have mixins, decorators, stamps, traits, and many utility libraries such as jQuery or underscore extend methods and ES6 brought Object.assign and classes, Every approach has its own benefits and drawback, and mastering these is something you can really turn to your advantage.

To further the confusion a bit 🙂 i think that object composition is a much better way to go when solving these kind of problems, but that is material for another article.


Say “thank you Stoyan, Addy and Douglas” out loud if you liked this article!