Let us continue the discussion about Prototypes in Javascript and show the different ways in which inheritance can work. Inheritance is very important because whether you are trying to extend the JQuery framework or trying to add custom event sources in Node.JS you will need to extend an existing JS object.
Let us remember the most important mantra in JS – “nearly everything interesting is an object, even functions”
Objects are mutable, primitives (e.g. strings) are NOT!
Let us first introduce the example. There is a base object: Person which has two properties ‘id’ and ‘age’ and getter/setter methods for these. We want to create a child object: Student, which should inherit the id and age properties from Person and add its own read-only ‘student id’ property.
[codesyntax lang=”javascript”]
/*
Base object: Person
*/
function Person(id)
{
this.id = 0;
this.age = 0;
}
/*
Add set/get methods for Age and Id
*/
Person.prototype.setId = function(id)
{
this.id = id;
};
Person.prototype.getId = function()
{
return this.id;
};
Person.prototype.setAge = function(age)
{
this.age = age;
};
Person.prototype.getAge = function()
{
return this.age;
};
/*
Child object Student which should extend properties and methods from Person
*/
function Student(sid)
{
this.sid = sid;
/*
Constructor for Person (to be safe)
*/
Person.call(this);
/*
Student Id getter
*/
Student.prototype.getSid = function()
{
return this.sid;
}
}
[/codesyntax]
There are different ways (patterns) of implementing ‘inheritance’ based (Inheritance Methods):
- Pattern 1: Student.prototype = Object.create(Student);
- Pattern 2: Student.prototype = Object.create(Person.prototype);
- Pattern 3: Student.prototype = new Person;
Below is the snippet of code we use to probe what happens in each of the three cases. Two instances of Student are created (s1 and s2). Then we examine the prototypes and assign values to some of the properties.
[codesyntax lang=”javascript”]
<Inheritance Method: one of the three options above>
var s1 = new Student(101);
var s2 = new Student(102);
console.log("S1",s1);
console.log("S2",s2);
console.log("Proto S1",Object.getPrototypeOf(s1));
console.log("Proto S2",Object.getPrototypeOf(s2));
if (Object.getPrototypeOf(s1) == Object.getPrototypeOf(s2)) {
console.log("Compare prototypes:",true);
}
console.log("\n\n");
s1.setId(1);
s1.setAge(30);
console.log("S1",s1.getAge());
s2.setId(2);
console.log("Compare Id S1:S2",s1.getId(),s2.getId());
s2.setAge(20);
console.log("S2 set age 20");
console.log("S1 age",s1.getAge());
console.log("S2 age",s2.getAge());
[/codesyntax]
Let us look at what happens in each case:
1) Student.prototype = Object.create(Student);
Output:
[codesyntax lang=”php”]
S1: { sid: 101, id: 0, age: 0 }
S2: { sid: 102, id: 0, age: 0 }
Proto S1: { getSid: [Function] }
Proto S2: { getSid: [Function] }
Compare prototypes: true
/Users/azaharmachwe/node_code/NodeTest/thisTest.js:73
s1.setId(1);
^
TypeError: Object object has no method 'setId'
at Object.<anonymous> (/Users/azaharmachwe/node_code/NodeTest/thisTest.js:73:4)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Function.Module.runMain (module.js:497:10)
at startup (node.js:119:16)
at node.js:901:3
[/codesyntax]
The surprising result is that an exception is thrown. It seems there is no method ‘setId’ on the Student instance. This means that inheritance did not work. We can confirm this by looking at the prototype of S1 and S2 instance. Only the getter for student id defined in the Student object is present. We have not inherited any of the methods from Person.
But if we look at the list of attributes we see ‘id’ and ‘age’ present. So it seems the attributes were acquired somehow.
If we look at the way we define the Person object we actually add the ‘id’ and ‘age’ attributes to the instance (i.e. we use this.id) where as the accessor methods are added on the prototype. When we create an instance of Student as Student.prototype = Object.create(Student) we correctly set the attributes as they are defined at the instance level.
If the line in bold is removed then you will only see the Student level attribute (‘sid’).
2) Student.prototype = Object.create(Person.prototype);
Output:
[codesyntax lang=”php”]
S1: { sid: 101, id: 0, age: 0 }
S2: { sid: 102, id: 0, age: 0 }
Proto S1: { getSid: [Function] }
Proto S2: { getSid: [Function] }
Compare prototypes: true
S1 30
Compare Id S1:S2 1 2
S2 set age 20
S1 age 30
S2 age 20
[/codesyntax]
No errors this time.
So we see both S1 and S2 instances have the correct attributes (Person + Student) prototypes for both contain the getter defined in Student and both have the same prototype. Something more interesting is the fact that we can set ‘age’ and ‘id’ on them as well showing us that the attribute setters/getters have been inherited from Person.
But why can’t we see the get/set methods for ‘age’ and ‘id’ on the Student prototype? The reason is that with the call to Object.create with the Person.prototype parameter we chain the prototype of Person with that of Student. To see the get/set methods for ‘age’ and ‘id’ that the Student instance is using add the following line to the probe commands:
console.log(“>>”,Student.prototype.__proto__);
This proves that the object is inheriting these methods at the prototype level and not at the object level. This is the recommended pattern for inheritance.
3) Student.prototype = new Person;
This is a method you may see in some examples out there. But this is not the recommended style. The reason is that in this case you are linking the prototype of Student with an instance of Person. Therefore you get all the instance variables of the super-type included in the sub-type.
Output:
[codesyntax lang=”php”]
S1: { sid: 101 }
S2: { sid: 102 }
Proto S1: { id: 0, age: 0, getSid: [Function] }
Proto S2: { id: 0, age: 0, getSid: [Function] }
Compare prototypes: true
S1 30
Compare Id S1:S2 1 2
S2 set age 20
S1 age 30
S2 age 20
[/codesyntax]
Note the presence of ‘id’ and ‘age’ attributes with default values in the prototypes of S1 and S2. If the attributes are array or object type (instead of a primitive type as in this case), we can get all kinds of weird, difficult to debug behaviours. This is the case with frameworks where a base object needs to be extended to add custom functionality. I came across this issue while trying to create a custom Node.JS event source.
Wrong way to extend: A Node.JS example
I have seen many Node.JS custom event emitter examples that use pattern number (3). The correct pattern to use is pattern (2). Let us see why.
The code below extends the Node.JS EventEmitter (in ‘events’ module) to create a custom event emitter. Then two instance of this custom event emitter are created. Different event handling callback functions for the two instances are also defined. This will allow us to clearly identify which instance handled the event.
In the end we cause the custom event to fire on both the instances.
[codesyntax lang=”javascript”]
var ev = require("events");
/*
Create a custom event emitter by extending the Node.JS event emitter
*/
function myeventemitter(id)
{
this.id = id;
ev.EventEmitter.call(this);
}
/*
Try different ways of extending
*/
myeventemitter.prototype = new ev.EventEmitter;
myeventemitter.prototype.fire = function()
{
console.log('\nFire',this.id);
this.emit('go',this.id);
}
/*
Initialise two instances of the custom event emitter
*/
var myee1 = new myeventemitter("A");
var myee2 = new myeventemitter("B");
/*
Define callbacks on the custom event ('go')
*/
myee1.on('go',function(id)
{
console.log("My EE1: Go event received from",id);
});
myee2.on('go',function(id)
{
console.log("My EE2: Go event received from",id);
});
/*
Cause the custom event to fire on both the custom event emitters
*/
myee1.fire();
myee2.fire();
/*
Dump the prototype of our custom event emitter
*/
console.log(myeventemitter.prototype);
[/codesyntax]
Note we are using pattern (3) to extend the EventEmitter:
myeventemitter.prototype = new ev.EventEmitter;
We expect that custom events fired on instance 1 will result in the event handling function on instance 1 being called. The same thing should happen for instance 2. Let us look at the actual output:
[codesyntax lang=”javascript”]
Fire A
My EE1: Go event received from A
My EE2: Go event received from A
Fire B
My EE1: Go event received from B
My EE2: Go event received from B
{ domain: null,
_events: { go: [ [Function], [Function] ] },
_maxListeners: 10,
fire: [Function] }
[/codesyntax]
This looks wrong! When we cause instance 1 to fire its custom event it actually triggers the event handling functions in both the instances! Same happens when we try with instance 2.
The reason as you may have already guessed is that when we use pattern (3) we actually attach the JSON object that holds the individual event handling functions to the prototype (variable name: _events). This can be seen in the above output.
Therefore both instances of the custom event emitter will have the same set of event handling functions registered because there is only one such set.
To correct this just switch the extension patter to (2):
[codesyntax lang=”javascript”]
Fire A
My EE1: Go event received from A
Fire B
My EE2: Go event received from B
{ fire: [Function] }
[/codesyntax]
The output now looks correct. Only the instance specific callback function is called and the prototype does not store the event handling functions. Therefore each instance of the custom event emitter has its own set for storing event handling functions.
Fish Eye View 