OOP In JavaScript: What You NEED to Know

»march. 19 2013 216

(Object Oriented JavaScript: Only Two Techniques Matter)

Bov Academy

of Programming and Innovation

Become an Elite/Highly Paid Specialized Software Engineer (Frontend, Fullstack, etc.)

Within 8–10 Months, Earn MORE than the Avg. New CS Graduate Earns. Guaranteed!

70%-Off Flash Sale for Just 5 Days! Ends October 16

By the founder of JavaScriptIsSexy

Prerequisite:
JavaScript Objects in Detail
JavaScript Prototype

Object Oriented Programming (OOP) refers to using self-contained pieces of code to develop applications. We call these self-contained pieces of code objects, better known as Classes in most OOP programming languages and Functions in JavaScript. We use objects as building blocks for our applications. Building applications with objects allows us to adopt some valuable techniques, namely, Inheritance (objects can inherit features from other objects), Polymorphism (objects can share the same interface—how they are accessed and used—while their underlying implementation of the interface may differ), and Encapsulation (each object is responsible for specific tasks).

In this article, we are concerned with only Inheritance and Encapsulation since only these two concepts apply to OOP in JavaScript, particularly because, in JavaScript, objects can encapsulate functionalities and inherit methods and properties from other objects. Accordingly, in the rest of the article, I discuss everything you need to know about using objects in JavaScript in an object oriented manner—with inheritance and encapsulation—to easily reuse code and abstract functionalities into specialized objects.

  • Receive Updates

We will focus on only the best two techniques1 for implementing OOP in JavaScript. Indeed, many techniques exist for implementing OOP in JavaScript, but rather than evaluate each, I choose to focus on the two best techniques: the best technique for creating objects with specialized functionalities (aka Encapsulation) and the best technique for reusing code (aka Inheritance). By “best” I mean the most apt, the most efficient, the most robust.

Encapsulation and Inheritance Overview

Objects can be thought of as the main actors in an application, or simply the main “things” or building blocks that do all the work. As you know by now, objects are everywhere in JavaScript since every component in JavaScript is an Object, including Functions, Strings, and Numbers. We normally use object literals or constructor functions to create objects.

Encapsulation refers to enclosing all the functionalities of an object within that object so that the object’s internal workings (its methods and properties) are hidden from the rest of the application. This allows us to abstract or localize specific set of functionalities on objects.

Inheritance refers to an object being able to inherit methods and properties from a parent object (a Class in other OOP languages, or a Function in JavaScript).

Both of these concepts, encapsulation and inheritance, are important because they allow us to build applications with reusable code, scalable architecture, and abstracted functionalities. Maintainable, scalable, efficient.


An instance is an implementation of a Function. In simple terms, it is a copy (or “child”) of a Function or object. For example:

// Tree is a constructor function because we will use new keyword to invoke it.
function Tree (typeOfTree) {} 

// bananaTree is an instance of Tree.
var bananaTree = new Tree ("banana");

In the preceding example, bananaTree is an object that was created from the Tree constructor function. We say that the bananaTree object is an instance of the Tree object. Tree is both an object and a function, because functions are objects in JavaScript. bananaTree can have its own methods and properties and inherit methods and properties from the Tree object, as we will discuss in detail when we study inheritance below.

OOP in JavaScript

The two important principles with OOP in JavaScript are Object Creation patterns (Encapsulation) and Code Reuse patterns (Inheritance). When building applications, you create many objects, and there exist many ways for creating these objects: you can use the ubiquitous object literal pattern, for example:

var myObj = {name: "Richard", profession: "Developer"}; 

You can use the prototype pattern, adding each method and property directly on the object’s prototype. For example:


function Employee () {}

Employee.prototype.firstName = "Abhijit";
Employee.prototype.lastName = "Patel";
Employee.prototype.startDate = new Date();
Employee.prototype.signedNDA = true;
Employee.prototype.fullName = function () {
console.log (this.firstName + " " + this.lastName); 
};

var abhijit = new Employee () //
console.log(abhijit.fullName()); // Abhijit Patel
console.log(abhijit.signedNDA); // true

You can also use the constructor pattern, a constructor function (Classes in other languages, but Functions in JavaScript). For example:


function Employee (name, profession) {
this.name = name;
this.profession = profession;
} // Employee () is the constructor function because we use the new keyword below to invoke it.

var richard = new Employee (“Richard”, “Developer”) // richard is a new object we create from the Employee () constructor function.

console.log(richard.name); //richard
console.log(richard.profession); // Developer

In the latter example, we use a custom constructor function to create an object. This is how we create objects when we want to add methods and properties on our objects, and when we want to encapsulate functionality on our objects. JavaScript developers have invented many patterns (or ways) for creating objects with constructor functions. And when we say Object Creation Patterns, we are concerned principally with the many ways of creating objects from constructor functions, as in the preceding example.

In addition to the patterns for creating objects, you want to reuse code efficiently. When you create your objects, you will likely want some of them to inherit (have similar functionality) methods and properties from a parent object, yet they should also have their own methods and properties. Code reuse patterns facilitate ways in which we can implement inheritance.

These two universal principles—creating objects (especially from constructor Functions) and allowing objects to inherit properties and methods—are the main focus of this article and, indeed, the main concepts with OOP in JavaScript. We first discuss the object creation pattern.

Encapsulation in JavaScript

(The Best Object Creation Pattern: Combination Constructor/Prototype Pattern)

As discussed above, one of the main principles with OOP is encapsulation: put all the inner workings of an object inside that object. To implement encapsulation in JavaScript, we have to define the core methods and properties on that object. To do this, we will use the best pattern for encapsulation in JavaScript: the Combination Constructor/Prototype Pattern. This name is a mouthful, but you needn’t memorize it, since we are only concerned with its implementation. Before we implement it, let’s quickly learn a bit more about the practicality of encapsulation.

Why Encapsulation?
When you simply want to create an object just to store some data, and it is the only object of its kind, you can use an object literal and create your object. This is quite common and you will use this simple pattern often.

However, whenever you want to create objects with similar functionalities (to use the same methods and properties), you encapsulate the main functionalities in a Function and you use that Function’s constructor to create the objects. This is the essence of encapsulation. And it is this need for encapsulation that we are concerned with and why we are using the Combination Constructor/Prototype Pattern.

To make practical use of OOP in JavaScript, we will build an object-oriented quiz application that uses all the principles and techniques we learn in this article. First up, our quiz application will have users (a Users Function) who take the quiz. There will be some common properties for every user who takes the quiz: each user will have a name, a score, an email, and the quiz scores (all the scores). These are the properties of the User object. In addition, each User object should be able to show the name and score, save scores, and change the email. These are the methods of the object.

Because we want ALL the user objects to have these same properties and methods, we cannot use the object literal way of creating objects. We have to use a constructor Function to encapsulate these properties and methods.

Since we know all users will have the same set of properties, it makes sense to create a Function (Class in OOP languages) that encapsulates these properties and methods. Thus, we will use the Combination Constructor/Prototype Pattern for this.

Implementation of Combination Constructor/Prototype Pattern
The User Function:

I will explain each line.

function User (theName, theEmail) {
    this.name = theName;
    this.email = theEmail;
    this.quizScores = [];
    this.currentScore = 0;
}

User.prototype = {
    constructor: User,
    saveScore:function (theScoreToAdd)  {
        this.quizScores.push(theScoreToAdd)
    },
    showNameAndScores:function ()  {
        var scores = this.quizScores.length > 0 ? this.quizScores.join(",") : "No Scores Yet";
        return this.name + " Scores: " + scores;
    },
    changeEmail:function (newEmail)  {
        this.email = newEmail;
        return "New Email Saved: " + this.email;
    }
}

Make Instances of the User function

// A User 
firstUser = new User("Richard", "Richard@examnple.com"); 
firstUser.changeEmail("RichardB@examnple.com");
firstUser.saveScore(15);
firstUser.saveScore(10); 

firstUser.showNameAndScores(); //Richard Scores: 15,10

// Another User
secondUser = new User("Peter", "Peter@examnple.com");
secondUser.saveScore(18);
secondUser.showNameAndScores(); //Peter Scores: 18

Explanation of Combination Constructor/Prototype Pattern
Let’s expound on each line of code so we have a thorough understanding of this pattern.

The following lines initialize the instance properties. These properties will be defined on each User instance that is created. So the values will be different for each user. The use of the this keyword inside the function specifies that these properties will be unique to every instance of the User object:

this.name = theName;
this.email = theEmail;
this.quizScores = [];
this.currentScore = 0;

In the code below, we are overwriting the prototype property with an object literal, and we define all of our methods (that will be inherited by all the User instances) in this object. Discussion continues after the code:

User.prototype = {
    constructor: User,
    saveScore:function (theScoreToAdd)  {
        this.quizScores.push(theScoreToAdd)
    },
    showNameAndScores:function ()  {
        var scores = this.quizScores.length > 0 ? this.quizScores.join(",") : "No Scores Yet";
        return this.name + " Scores: " + scores;
    },
    changeEmail:function (newEmail)  {
        this.email = newEmail;
        return "New Email Saved: " + this.email;
    }
}

This way of overwriting the constructor is simply for convenience, so we don’t have to write User.prototype each time, like this:


User.prototype.constructor = User;
User.prototype.saveScore = function (theScoreToAdd)  {
    this.quizScores.push(theScoreToAdd)
};

User.prototype.showNameAndScores = function ()  {
    var scores = this.quizScores.length > 0 ? this.quizScores.join(",") : "No Scores Yet";
    return this.name + " Scores: " + scores;
};

User.prototype.changeEmail =  function (newEmail)  {
    this.email = newEmail;
    return "New Email Saved: " + this.email;
}

By overwriting the prototype with a new object literal we have all the methods organized in one place, and you can better see the encapsulation that we are after. And of course it is less code you have to type.

JavaScript Prototype
In JavaScript, you add methods and properties on the prototype property when you want instances of an object to inherit those methods and properties. This is the reason we add the methods on the User.prototype property, so that they can be used by all instances of the User object. Read more about JavaScript Prototype in Plain Language.

Constructor Property
In my post JavaScript Prototype, I explained that every function has a constructor property, and this property points to the constructor of the function. For example:

function Fruit () {}
var newFruit = new Fruit ();
console.log (newFruit.constructor) // Fruit ()

The one disadvantage of overwriting the prototype is that the constructor property no longer points to the prototype, so we have to set it manually. Hence this line:


constructor: User

Prototype Methods
In the following lines, we create methods on the prototype (in the object literal) so that all instances of Users can have access to these methods.

saveScore:function (theScoreToAdd)  {
        this.quizScores.push(theScoreToAdd)
    },
    showNameAndScores:function ()  {
        var scores = this.quizScores.length > 0 ? this.quizScores.join(",") : "No Scores Yet";
        return this.name + " Scores: " + scores;
    },
    changeEmail:function (newEmail)  {
        this.email = newEmail;
        return "New Email Saved: " + this.email;
    }

We then created instances of the User object:

// A User 
firstUser = new User("Richard", "Richard@examnple.com"); 
firstUser.changeEmail("RichardB@examnple.com");
firstUser.saveScore(15);
firstUser.saveScore(10); 

firstUser.showNameAndScores(); //Richard Scores: 15,10

// Another User
secondUser = new User("Peter", "Peter@examnple.com");
secondUser.saveScore(18);
secondUser.showNameAndScores(); //Peter Scores: 18

As you see, we have encapsulated all the functionality for a User inside the User Function, so that each instance of User can make use of the prototype methods (like changeEmail) and define their own instance properties (like name and email).

With this pattern, you can use the standard operators and methods on the instances, including the instanceOf operator, the for-in loop (even hasOwnProperty), and the constructor property.

Inheritance in JavaScript

(The Best Pattern: Parasitic Combination Inheritance)

Implementing inheritance in our quiz application will permit us to inherit functionality from parent Functions so that we can easily reuse code in our application and extend the functionality of objects. Objects can make use of their inherited functionalities and still have their own specialized functionalities.

The best pattern for implementing inheritance in JavaScript is the Parasitic Combination inheritance 2. Before we dive into this awesome pattern, let’s see why its practical to use inheritance in our applications.

We have successfully implemented encapsulation by enclosing all the functionality for users of our quiz application by adding all the methods and properties that each user will need on the User function, and all instances of User will have those properties and methods.

Why Inheritance?

Next, we want to encapsulate all the functionalities for every Question. The Question function (Class in OOP languages) will have all the generic properties and methods that every kind of question will need to have. For example, every question will have the question, the choices, and the correct answer. These will be the properties. In addition, each question will have some methods: getCorrectAnswer and getUserAnswer, and displayQuestion.

We want our quiz application to make different types of Questions. We will implement a MultipleChoiceQuestion function and a DragDropQuestion function. To implement these, it would not make sense to put the properties and methods outlined above (that all questions will use) inside the MultipleChoiceQuestion and DragDropQuestion functions separately, repeating the same code. This would be redundant.

Instead, we will leave those properties and methods (that all questions will use) inside the Question object and make the MultipleChoiceQuestion and DragDropQuestion functions inherit those methods and properties. This is where inheritance is important: we can reuse code throughout our application effectively and better maintain our code.

Since the MultipleChoiceQuestion HTML layout and will be different from the DragDropQuestion HTML layout, the displayQuestion method will be implemented differently in each. So we will override the displayQuestion method on the DragDropQuestion. Overriding functions is another principle of OOP.

Lets Code.

Implementing the Parasitic Combination Inheritance Pattern

To implement this pattern, we have to use two techniques that were invented specifically for inheritance in JavaScript. Some notes about these techniques follow. No need to memorize any of the detail; just understand and be aware of the techniques.

Prototypal Inheritance by Douglas Crockford

Douglas Crockford created the following Object.create method 3, used in a fundamental way to implementing inheritance with the pattern we are using.

Object.create method
Ruminate on the method Crockford created:

 if (typeof Object.create !== 'function') {
    Object.create = function (o) {
        function F() {
        }

        F.prototype = o;
        return new F();
    };
}

This method has been added to the ECMAScript5 specification, and you can access it with Object.create (). Let’s quickly understand it is doing.

Object.create = function (o) {
//It creates a temporary constructor F()
        function F() {
        }
//And set the prototype of the this constructor to the parametric (passed-in) o object
//so that the F() constructor now inherits all the properties and methods of o
        F.prototype = o;

//Then it returns a new, empty object (an instance of F())
//Note that this instance of F inherits from the passed-in (parametric object) o object. 
//Or you can say it copied all of the o object's properties and methods
        return new F();
    }

The crux of the matter with this Object.create method is that you pass into it an object that you want to inherit from, and it returns a new object that inherits from the object you passed into it. For example:

// We have a simple cars object
var cars = {
    type:"sedan",
    wheels:4
};

// We want to inherit from the cars object, so we do:
var toyota = Object.create (cars); // now toyota inherits the properties from cars
console.log(toyota.type); // sedan

Of course we can now add more properties to the toyota object, but let’s move on.

The next function we will use for inheritance is the inheritPrototype function. This function succinctly implements the parasitic combination inheritance for us. We pass in the parent object (or Super Class) and the child object (or Sub Class), and the function does the parasitic combination inheritance: makes the child object inherits from the parent object.

 function inheritPrototype(childObject, parentObject) {
    // As discussed above, we use the Crockford’s method to copy the properties and methods from the parentObject onto the childObject
// So the copyOfParent object now has everything the parentObject has 
    var copyOfParent = Object.create(parentObject.prototype);

    //Then we set the constructor of this new object to point to the childObject.
// Why do we manually set the copyOfParent constructor here, see the explanation immediately following this code block.
    copyOfParent.constructor = childObject;

    // Then we set the childObject prototype to copyOfParent, so that the childObject can in turn inherit everything from copyOfParent (from parentObject)
   childObject.prototype = copyOfParent;
}

Why did we manually set the copyOfParent.constructor?
________________________________________
We explicitly set the copyOfParent.constructor property to point to the childObject constructor because in the preceding step, var copyOfParent = Object.create(parentObject.prototype), this is what we actually did:

// We made a new object and overwrote its prototype with the parentObject prototype:
function F() {
        }
F.prototype = parentObject.prototype;
// Then it was this new F object we assigned to copyOfParent.
// All of this was done inside the Object.create () method.

So, this new F object, which we assigned to copyOfParent, doesn’t have a constructor property anymore because we overwrote its entire prototype. Whenever you overwrite an object’s prototype (object.prototype = someVal), you also overwrite the object’s constructor property.

To make sure we have the correct value for copyOfParent constructor, we set it manually with this:
copyOfParent.constructor = childObject;

A commenter by the name of John correctly pointed our that I did not corruptly explain this bit, hence this detailed explanation.
________________________________________

Essentially, we are copying all the properties and methods from the parentObject to the childObject, but we are using the copyOfParent as an intermediary for the copy. And because the childObject prototype was overwritten during the copy, we manually set the copyOfParent constructor to the childObject. Then we set the childObject prototype to the copyOfParent so that the childObject inherits from the parentObject.

Okay, that was quite a bit. I am hopeful you understand some of that :).

Back to the fun stuff: Creating our quiz OOP style.
Now that we understand the inheritPrototype function we will be using, lets go ahead and implement our Question constructor.

Note that I use “constructor” and “function” interchangeably sometimes in this particular article when referring to the function, because the function will be used as a constructor to create instances.

The Question Constructor (Parent of all Question Objects):
(Can be thought of as the Super Class for Questions)

 // The Question function is the parent for all other question objects;
// All question objects will inherit from this Question constructor

function Question(theQuestion, theChoices, theCorrectAnswer) {
    // Initialize the instance properties
    this.question = theQuestion;
    this.choices = theChoices;
    this.correctAnswer = theCorrectAnswer;
    this.userAnswer = "";

    // private properties: these cannot be changed by instances
    var newDate = new Date(),
    // Constant variable: available to all instances through the instance method below. This is also a private property.
        QUIZ_CREATED_DATE = newDate.toLocaleDateString();

// This is the only way to access the private QUIZ_CREATED_DATE variable 
// This is an example of a privilege method: it can access private properties and it can be called publicly
    this.getQuizDate = function () {
        return QUIZ_CREATED_DATE;
    };

// A confirmation message that the question was created
    console.log("Quiz Created On: " + this.getQuizDate());

}

Add Prototype Methods to The Question Object
All instances of the Question object will inherit these methods, because we are adding the methods on the Question prototype.

 // Define the prototype methods that will be inherited
Question.prototype.getCorrectAnswer = function () {
    return  this.correctAnswer;
};

Question.prototype.getUserAnswer = function () {
    return this.userAnswer;
};

Question.prototype.displayQuestion = function () {
    var questionToDisplay = "<div class='question'>" + this.question + "</div><ul>";
        choiceCounter = 0;

    this.choices.forEach(function (eachChoice)  {
        questionToDisplay += '<li><input type="radio" name="choice" value="' + choiceCounter + '">' + eachChoice + '</li>';
        choiceCounter++;
    });
    questionToDisplay += "</ul>";

    console.log (questionToDisplay);
}; 

Child Questions (Sub Classes of the Question object)
Now that we have the Question constructor object setup, we can inherit from it and create sub classes (children objects). The power of inheritance is that we can create all sorts of questions now, and each can be quite versatile.

First, a Multiple Choice Question:

// Create the MultipleChoiceQuestion
function MultipleChoiceQuestion(theQuestion, theChoices, theCorrectAnswer){
// For MultipleChoiceQuestion to properly inherit from Question, here inside the MultipleChoiceQuestion constructor, we have to explicitly call the Question constructor
// passing MultipleChoiceQuestion as the this object, and the parameters we want to use in the Question constructor:
    Question.call(this, theQuestion, theChoices, theCorrectAnswer);
};

And then we have to use the inheritPrototype function we discussed moments ago:

// inherit the methods and properties from Question
inheritPrototype(MultipleChoiceQuestion, Question);

After we have inherited from Question, we then add methods to the MultipleChoiceQuestion function, if necessary. But we must do it after we inherit, not before, or all the methods we define on its prototype will be overwritten. We are not adding any now.

A Drag and Drop Question
In a similar manner, we can make yet another type of question:

// Create the DragDropQuestion
function DragDropQuestion(theQuestion, theChoices, theCorrectAnswer) {
    Question.call(this, theQuestion, theChoices, theCorrectAnswer);
}

// inherit the methods and properties from Question
inheritPrototype(DragDropQuestion, Question);

Overriding Methods
Overriding methods is a another principle of OOP, and we can do it easily with this pattern. Since the Drag and Drop questions will have a different HTML layout from the Multiple Choice questions (no radio buttons, for example), we can override the displayQuestion method so it operates specifically to the Drag and Drop question needs:

// Override the displayQuestion method it inherited
DragDropQuestion.prototype.displayQuestion = function () {
    // Just return the question. Drag and Drop implementation detail is beyond this article
    console.log(this.question);
};

In our real Quiz application, we would create a Quiz constructor that is the main application that launches the quiz, but in this article, we can test our inheritance code by simply doing this:

// Initialize some questions and add them to an array
var allQuestions = [
new MultipleChoiceQuestion("Who is Prime Minister of England?", ["Obama", "Blair", "Brown", "Cameron"], 3),
   
new MultipleChoiceQuestion("What is the Capital of Brazil?", ["São Paulo", "Rio de Janeiro", "Brasília"], 2),
   
new DragDropQuestion("Drag the correct City to the world map.", ["Washington, DC", "Rio de Janeiro", "Stockholm"], 0)
];

// Display all the questions
allQuestions.forEach(function (eachQuestion)  {
    eachQuestion.displayQuestion();
});

If you run the code, you will see that the displayQuestion for the multiple choice questions returns the question in a div tag, with choices formatted with radio buttons inside li tags. On the other hand, the drag and drop questions displayQuestion method simply returns the question without the choices.

Nicholas Zakas stated it wonderfully, “Parasitic combination inheritance is considered the most optimal inheritance paradigm” 5 in JavaScript. If you learn it and understand it well, you should use it in your JavaScript web applications.

You might be wondering how is the Combination Constructor/Prototype Pattern we used for Encapsulation earlier different from the Parasitic Combination Inheritance. They are similar, but the former is best used for encapsulation (creating custom objects), and it does not have all the inheritance mechanisms such as subclassing (creating child constructors that inherit from the parent constructor). Moreover, the inheritance pattern goes beyond setting up objects to just inherit properties and methods, it enables child objects to themselves be parent objects of other objects, and you can use private members, overriding, and other OOP concepts.

Final Words

I gave you the full details for implementing the best two patterns for OOP in JavaScript, and I am hopeful you understood at least the general concepts. Go use these patterns in your JavaScript applications. Note that you can use OOP in even small and medium applications, not just complex applications.

Be good and do good work, and take care of yourself: sleep well, eat well, and enjoy life.

Further Reading

Read chapters 6 and 7 of Zakas’s Professional JavaScript for Web Developers.
Read chapters 5 and 6 of Stefanov’s JavaScript Pattens.
Read chapter 4 of Herman’s Effective JavaScript.

Notes

  1. Professional JavaScript for Web Developers Chapter 6.
  2. JavaScript Patterns Chapters 5 and 6
  3. Effective JavaScript: 68 Specific Ways to Harness the Power of JavaScript Chapter 4.
  4. http://javascript.crockford.com/prototypal.html
  5. Professional JavaScript for Web Developers Chapter 6, page 215.

216 Comments

  1. Anthony

    I was just doing the same-thing tonight before I found your article!
    var config = {
    writable: true,
    enumerable: true,
    configurable: true
    }

    var defineProperty = function(obj, name, value) {
    config.value = value;
    Object.defineProperty(obj, name, config);
    }

    var man = Object.create(null);
    defineProperty(man, ‘sex’, ‘male’);

    var tony = Object.create(man);
    defineProperty(tony, ‘firstName’, ‘Tony’);
    defineProperty(tony, ‘lastName’, ‘Brown’);

    alert.log(tony.sex);
    alert(tony.firstName);
    alert(tony.lastName);

    console.log(Object.getPrototypeOf(tony));

  2. Anthony

    Excellent article, as usual Richard! I commend you for your work and promotion of the JavaScript language!

    • Richard Bovell (Author)

      Thanks, Man. I appreciate it. Some of these articles take quite a bit of time to write. I always think I will finish in some length of time, but the articles more often than not seem to take twice as long.

  3. Thanawat

    Another great article, Richard.

    One thing, in the snippet function inheritPrototype
    Should
    var copyOfParent = Object.create(superType.prototype);
    be
    var copyOfParent = Object.create(parentObject.prototype);

  4. Jurgen

    Thank you for these wonderful articles. I have read through your previous articles on objects and prototype, but I can’t seem to understand the real difference (if any) between the following two pieces of code:

    function Test (theVariable) {
    this.variable = theVariable;
    this.variable2 = ‘Some text ‘;
    this.someMethod = function () {
    console.log(this.variable2 + this.variable);
    }
    }

    and:

    function Test (theVariable) {
    this.variable = theVariable;
    }
    test.prototype = {
    constructor : Test,
    variable2 : ‘Some text ‘;
    someMethod : function () {
    console.log(this.variable2 + this.variable);
    }
    }

    Thanks a lot!

    • Richard Bovell (Author)

      Good question, Jurgen.

      The two examples will function exactly the same with your test code. But they are fundamentally different.

      In the former, all the properties and methods are defined on the instance, so the values will be unique to each instance. You can see the issue better if we use a reference type (Array or Objects). I changed your code and made variable2 an array.

      
      // Constructor Pattern
      function Test(theVariable) {
          this.variable = theVariable;
          this.variable2 = ["Mike", "Anil"];
          this.someMethod = function () {
              console.log(this.variable2 + this.variable);
          }
      }
      
      var aTest = new Test ("-- Testing");
      aTest.variable2.push("Richard");
      aTest.someMethod(); // Mike,Anil,Richard -- Testing
      
      var anotherTest = new Test ("-- Testing");
      anotherTest.variable2.push("Jurgen");
      // Array is unique to the anotherTest instance
      anotherTest.someMethod(); //Mike,Anil,Jurgen-- Testing
      
      // variable2 was not changed by the anotherTest instance:
      aTest.someMethod(); // Mike,Anil,Richard-- Testing
      

      In your latter example, however, only this.variable is an instance variable, so it will be unique always. All the properties and methods defined on the prototype will be inherited by all instances of Test, and all instances will have the same values (for reference types) for those. For example:

      
      function Test(theVariable) {
          this.variable = theVariable;
      }
      
      Test.prototype = {
          constructor:Test,
          variable2:["Mike", "Anil"],
          someMethod:function () {
              console.log(this.variable2 + " " +  this.variable);
          }
      }
      
      
      var aTest = new Test ("-- Testing");
      aTest.variable2.push("Richard");
      aTest.someMethod(); // Mike,Anil,Richard -- Testing
      
      var anotherTest = new Test ("-- Testing");
      anotherTest.variable2.push("Jurgen");
      
      // Uses the same array from the prototype (Richard is included)
      anotherTest.someMethod(); // Mike,Anil,Richard,Jurgen -- Testing
      
      
      // variable2 changed on ALL instances:
      aTest.someMethod(); // Mike,Anil,Richard,Jurgen -- Testing
      
      • Jurgen

        Oh wow, that makes a lot of sense. Thank you for clearing this up, I learned a lot today!

      • kishore

        I have small doubt. If I override someMethod function in anotherTest object, will it effect in aTest object? can I override like below code
        anotherTest.prototype.someMothod = function(){
        console.log(“hi”)
        }

    • Peter

      This might be a stupid question, but can this be considered as a static class?

    • Stefano Pongelli

      A bit late to the party, let me add something: the main difference between using prototypes and declaring functions inside the constructor, is that if you do not use prototypes, each time you create a ‘new’ object you will also recreate all the functions that are inside the constructor.

      The same does not apply if you use prototypes: it could mean a lot memory-wise!

      • Nikolaj Larsen

        I always wondered what the difference was.

        I guess another difference would be that the method declared on ‘this’ inside the constructor would yield true from the hasOwnProperty method, whereas the method declared on the prototype would be false

        But if methods on the prototype cannot access private properties declared in the constructor of the class/function, whether to use one or the other way of declaring methods, would be a tradeof of whether you’re able to hide properties or not. Said in another way, only methods that doesn’t require access to private properties can be declared in the prototype. Am I completely off here?

  5. Domen

    I feel so bad that you put so much time and work doing this for free. Why not add non-intrusive ads on your website?

    • Richard Bovell (Author)

      This is very thoughtful of you, Domen. Thanks very much.

      I am not sure I will add Ads to the site, but if I do, the Ads will be inconspicuous, like they are on this site:
      http://daringfireball.net/

      And it is great that you are studying JS at such a young age. All the best with your career.

      I plan to make some sexy T-shirts for the site :), so this will help.

  6. Anthony

    @Domen, why don’t you send him a donation than? I hate ads >_<

    • Domen

      I’m 18 years old student, who is moving away from parents in 3 months, without job nor credit card (paypal) to make a donation with money I currently have. 😛

      If I get credit card anytime soon, I will certainly make a donation. :)

  7. Anthony

    Grammar fix:
    “And it this need for encapsulation that we are concerned with and why we are using the Combination Constructor/Prototype Pattern.”
    Should be this:
    And it is this need for encapsulation that we
    are concerned with and why we are using the
    Combination Constructor/Prototype Pattern.

  8. DB

    I’ve been doing JavaScript development for a long time and this is one of the best explanations of OOP in JS I think I’ve ever seen. Good job!

    • Richard Bovell (Author)

      Thanks much, DB.
      My goal is always to explain the complex topics in manner than anyone can understand, so I feel that my goal for this post has been accomplished, after reading your comment :)

  9. You’re overcomplicating a few things here, and putting too much emphasis on constructors. Prototypal inheritance gets even simpler in JavaScript. See http://ericleads.com/2013/02/fluent-javascript-three-different-kinds-of-prototypal-oo/

    • Anthony

      I have to disagree with you, these examples are for learning and not for showing how terse JavaScript can be

      • It’s not about terseness. It’s about avoiding the coupling between the child and the parent. There is no tighter coupling than that created by the relationship between child and parent objects, and tight coupling is exactly what you want to avoid to get flexible OO design.

        I’m giving a talk on this at the O’Reilly Fluent conference titled, “Classical Inheritance is Obsolete: How to Think in Prototypal OO”.

        Come check it out: http://www.dpbolvw.net/click-7037282-11284265

        Or watch my blog for video.

        • Anthony

          Eric I read your blog too, I also started reading your book on Oreilly’s rough cuts. I’ve asked you several times for a discount and you have ignored me on each occasion to.
          I find it a little rude that you are soliciting Richards readers in the comments.
          JavaScript is a highly expressive language and there are a dozen ways to get to a certain end result and I appreciate different viewpoints on this. I give you big credit for your work but I also love how Richard writes and more importantly communicates with his audience, something you should probably try and do more of . I do apologize for my remark on javascript being terse, I jumped the gun before I read the post in it’s entirety. They both are good examples of OO in JavaScript and I thank both of you with all sincerity

          • Hi Anthony,

            I do respond to comments on my blog, but between the book writing and my full-time gig, I can’t always respond the same day. I know the comment you’re referring to, and I did respond. See: http://ericleads.com/javascript-applications/#comment-8900

            I also communicate with readers extensively. I actively engage the community at large, including my comments on other blogs (like this one). I speak at conferences, and hang around and answer questions in person. I am an active member of the popular JavaScript communities on Google+. I engage with readers on Facebook (I maintain a page for my book with ~6k fans), I’ve scheduled a whole week to answer questions from readers (and potential readers) on the CodeRanch forums, and I frequently answer questions on freenode IRC in ##javascript, #node, and #jquery. I don’t think I can squeeze any more engagement in, but I’ll try. Thanks for the suggestion. 😉

            The reason I felt the need to post a response here is because Richard is claiming that his preference for inheritance is the “best”. I call these strong statements comment bait. He opened the door, so I walked in.

            Some people agree with him. I don’t. Dissenting opinions are a good thing. It should encourage all of us to do more critical thinking, and hopefully question our own understandings of the language, and obtain a better understanding as a result.

            I think Richard’s blog is great. I’m glad he maintains it, and I’m glad he’s open to feedback from blow-hards like me. 😉

            He obviously put a lot of thought into this article, and I can’t deny that it could help people gain a better understanding of working with objects in JavaScript.

            I hope both of you stay engaged, and I look forward to our next conversation. =)

          • Anthony

            Cheers Eric

          • Anthony, in response to your comment about not engaging enough, I’ve redesigned my blog with links to my social media pages, and the ability for users to register for my newsletter to get JavaScript news, my upcoming speaking events, webinars, and other opportunities to interact.

            How did I do?

    • Richard Bovell (Author)

      Eric, you could be correct that simple Prototypal Inheritance on its own is probably “simpler” (for some developers) than the Parasitic Combination Inheritance Pattern I discuss in the article. But note that I discuss only the best pattern for inheritance in JavaScript.

      Indeed, there are many patterns for implementing inheritance in JS, such as Factory, Parasitic, Rent A Constructor, Prototype Chaining, Combination Inheritance (the most popular of the lot), Prototypal, and others. It is up to the developer to decide which is easier, but I only discuss the best (most optimal) pattern. I don’t think it is necessary for developers to know and learn all the patterns or the simplest (not the most optimal) one.

      To learn more about the advantages and disadvantages of each pattern, read Zakas’s Professional JavaScript for Web Developers (Chapter 6) and Stefanov’s JavaScript Patterns (Chapters 5 and 6).

      • Hi Richard,

        What was your criteria to decide the “best”?

        I have read both books, and written about JavaScript inheritance in my own O’Reilly book, “Programming JavaScript Applications”.

        • Richard Bovell (Author)

          Eric,

          In Professional JS for Web Developers (3rd Edition), Nicholas C. Zakas was explicit when he described the best (“most most optimal”) two patterns. And he painstakingly explained how those two patterns improved on all the other patterns, comparing the advantages and disadvantages of each.

          I have not personally researched all the many patterns and test and compare each, so I am not qualified to debate this topic at length.

          • Yeah, he did discuss a lot of patterns, but one thing they all had in common was that they were mostly based on using prototypal inheritance to mimic the techniques used in classical OO — specifically, the establishment of the parent/child links.

            Those links though are completely unnecessary in prototypal languages capable of dynamic object extension. Take a look at my stampit examples and see if you can figure out why I like it better.

    • Richard Bovell (Author)

      Eric,
      I am looking forward to your “Programming JavaScript Applications” books. The outline looks good.

      Also, your post, “Switch … Case Considered Harmful,” is an informative post, I have never seen objects (method lookup) being used in place of switch statements:
      Switch … Case Considered Harmful

      • Anthony

        Crockford doesn’t like using switch in JavaScript as well, I can’t find the post where he talks about it though.

        • I believe Crockford addressed his concerns about switch statement fallthrough in “The Good Parts”. However, he still uses switch statements in his code (to my knowledge), and simply avoids using the fallthrough feature.

          Interestingly, a friend of mine informed me that fallthrough will throw an error in C# compilers. Apparently we’re not the only ones who think it’s problematic. =)

          • Anthony

            They work in AS3, but even though they look sexy, I avoid them in JavaScript because of what Crockford said.
            Do you know why they are so problematic Eric?
            do you know when that video is going to up of the Fluent conference too?

          • Fallthrough is problematic primarily because it’s really easy to forget the break, and because you might leave break off intentionally when you employ fallthrough, a forgotten break is much harder to catch than say, a forgotten bracket.

            Crockford argues that you should never use the fallthrough feature, so you know that any forgotten break is an error.

            I argue that switch statements in general get abused and messy as cases get added, and eventually turn into a giant spaghetti bowl, whereas method lookup tends to do a better job of ensuring that all the cases are related. At the same time, method lookup allows for more flexibility and better extensibility.

            Given that they’re also faster than switch statements, and have no fallthrough feature to worry about, I don’t see a compelling argument to ever use switch in JavaScript. I haven’t written a switch statement for production code for several years.

          • Anthony

            Slow, I don’t like that word lol
            every little bit helps, because it’s the little things that add up and clobber you when your app grows. Yea I don’t use them neither

          • It’s really funny that you mentioned slow in this context. I just finished writing a blog post about knowing what to optimize. http://ericleads.com/2013/04/youre-optimizing-the-wrong-things/

          • Richard Bovell (Author)

            Great article, Eric. I just tweeted about it.

      • Hi Richard,

        I’m participating in the O’Reilly Blogger Review program if you’d like to get an advance copy for review. http://oreilly.com/bloggers/

        • Richard Bovell (Author)

          Ok, thanks for the invite, I will give it a go. I actually need a better book than “JavaScript Patterns” to recommend for my Learn Advanced JavaScript post. I am not completely happy with that book, and none of the other (Adv. books) out there is much better.

          There is no single great advanced JavaScript book that I have seen. So if your book is great (or even better than just the JS Patterns book), I will replace the JS Patterns book with it on the Learn Adv JavaScript post.

  10. First off, thanks for creating such a informative and well designed website. It’s really slick. I have been trying to learn for JS for a while, but only recently have been making progress…(Followed your post on “how to learn js” and just purchased Professional JS for Web Developers).
    Question: I have read in many arenas creating methods via the prototype is the way to go. The rational is the subsequent new Object will inherit those methods only once, (and there’s a memory issue happening)rather than if one had placed said method in a constructor. So that can one use it with properties too?
    If so why wouldn’t we always create our objects via prototypes? Seems like an extra step?

    • Richard Bovell (Author)

      Hi Antonio, I am not sure I understand your question. Could you rephrase your question? I would be happy to answer you once I understand precisely what you mean.

      Thanks.

      • Sorry, I wrote that at work!
        From what I have gleaned from other resources, you use the Constructor pattern to make objects. But I have also read, when you’re giving that Constructor a method, you don’t want to make it in the Constructor, you use it’s prototype (which every function has inherently) instead.
        The reason being, if you create the method in the original Constructor, when you create a new object from that Constructor that method would be copied every time, causing memory problems.
        So I guess my question is why wouldn’t you create the object using the prototype pattern in the first place?

        • Richard Bovell (Author)

          That is a very good question, Antonio.

          First, in the examples (the two patterns we use) in the article above, note that we are using the prototype to define the methods and properties. But we are using more than just the prototype, because the Prototype Pattern alone has some disadvantages.

          The main disadvantage with the Prototype Pattern is that all the properties are inherited and shared by all the instances, and when you change a prototype property on one, it is reflected on all of them. This is particularly true for reference types. Look at the discussion Jurgen and I had above. I touched on this. He had a similar question.

          Also, neither of the two patterns I use above use the full Constructor Pattern. They only use the Constructor to define instance properties. There is no memory problem with the Constructor properties. Only Constructor methods can cause memory issues.

          But note that I only have one method defined in the Constructor (this.getQuizDate), and it is not necessary. I only added it there as an example of a private method. All it does it show the date the quiz was created. We can easily add it on the prototype.

          Your point is noted though, because you are correct that methods defined in the Constructor will be recreated for each instance, and thus use memory. So if you have a lot of instances and a lot of Constructor methods, then the memory issue could be a problem. We don’t have this problem, since we only have the one unnecessary (this.getQuizDate) method defined in the Constructor.

  11. Anthony

    Finally got a chance to go through the code more thoroughly, and caught another typo Richard. in the Question constructor you have an extra var keyword in front of the QUIZ_CREATED_DATE variable/constant.

    Thanks again for tour of OO inheritance in JavaScript, are you going to a take on the prototypical qualities of the language ?

  12. Bhawani Singh

    Nice post!!!!!!!! keep it up

  13. Thanks. I found that your blog is very useful. How can I keep informed of your posts instead of visiting here manually?

    • Richard Bovell (Author)

      Many users have inquired about a mailing list, but I don’t want to send out emails. You can follow me on Twitter, where I announce when I publish a new article. Or you can check the box “Notify me of new posts via email” that you see when you are adding a comment.

  14. Tyrone Michael Avnit

    One of the more informative articles I have read lately. Thanks for explaining it with such ease. Will definitely be subscribing the the blog.

  15. Abhinav Arora

    Hi Richard…amazing work. this is surely the best thing out there on JS. I have been learning javascript like you said. Could you please suggest me some open source projects where I can practice and hone the newly aquired skills.

    Appreciate the effort. Hats Off to you man!!

    • Richard Bovell (Author)

      Thanks much, Abhinav.
      I don’t which specific project would be ideal for you, but I recommend you look for “javascript” projects on GitHub, of which there are quite a lot. And most them need contributors.

  16. Hey Richard, thanks a lot for these hight quality informations. I’m curious when you say “inheritance and encapsulation” only applicable on OOP in JavaScript. After I read a article about polymorphism in OOP JS here: http://www.codeproject.com/Articles/315169/Polymorphism-in-JavaScript. What you think about it? Thanks!

    • Richard Bovell (Author)

      Many OOP purists like to add OOP principles to JavaScript that are common in languages OOP languages like Java. But it is unnecessary to do this in JavaScript, and the result is usually complex code that is not always productive.

      Suffice to say, these OOP principles like polymorphism and Interfaces, amongst others, are not necessary in JS and they are’t worth the time and effort for JS developers.

  17. Nick

    Great article and I expanded my js knowledge even more. I have been writing some semi-complicated applications and it always seems to string along so I decided to read up some and this article will definitely come in handy. Although I do have one question. When making the MultpleChoiceQuestion you did this inside the function:

    Question.call(this, theQuestion, theChoices, theCorrectAnswer);

    Now when I was playing with this myself I found that I could just do:

    this.constructor.apply(this,arguments);

    I was wondering if there were any drawbacks to this or any reason why you didn’t do this. In my head I am thinking it is better because it will use whatever constructor you tell it to use (so if you were to change constructor wouldn’t have to worry about updating the calls everywhere) and it will also allow you to add additional arguments without having to update each of the inherited classes. I am not sure if there is something I am missing but I figured it was worth seeing if you had any input on this.

    • Richard Bovell (Author)

      Nick,

      The style you have written for handling the arguments is totally fine. It is mostly used for variable-arity functions (functions that can take any number of arguments). And you see it quite often in JS libraries.

      So, go for it, since you like that style.

  18. Tyler

    I know you are busy, but I miss reading your blog. Looking forward to your next post!

  19. Gopala Krishna Bala

    I am a web developer, wants to receive the updates

  20. Alex Hurtt

    I am curious as to why you choose the approach of overwriting the implicit prototype of a function/object with your own anonymous object like so:

    function F() {}
    F.prototype = {
    constructor:F,
    someFunction:function(){}
    }

    as opposed to just this:

    function F() {}
    F.prototype.someFunction = function() {}

    In other words, what is the advantage or at least the reason behind the choice of overwriting/redefining the implicit prototype object with one of your own creation and having to explicitly delare the constructor property?

    • Richard Bovell (Author)

      Great question, Alex.
      First, it is important that I clarify one note in your comment: the Prototypal Inheritance function that you inquired about, which is shown in code below, was created by the venerable JavaScript master Douglas Crockford. I did not create it.

      Here is the code again, for clarity:

      Object.create = function (o) {
              function F() {
              }
      
              F.prototype = o;
              return new F();
          };
      

      I think the reason Crockford overwrites the entire prototype is to implement a full copy of the “o” object, and thus the new F () object that is returned inherits completely from the “o” object (the F object is a shadow copy of the “o” object).

      Simply put, you pass in an object to the function when you want to make a full copy of it (or to inherit fully from it). This is the reason for the full prototype overwrite, I presume.

      • That function simply creates a new object with whatever object you pass in as its prototype.

        F() is a constructor function that gets called with `new` to instantiate a new object that has a reference to whatever object you pass in as “o”.

        In other words, to inherit from some prototype, “foo”, you would do:
        var bar = Object.create(foo);

        “foo” is “o” inside the function.

  21. JavaScript is an excellent language to write object oriented web applications. It can support OOP because it supports inheritance through prototyping

  22. Elie GAKUBA

    Thank you Richard. It is a good practice.

  23. Hi Richard

    I have been following your posts since last week. Really these are superb. i have learned a lot from your posts. Now i get a confidence that i can implement OOP concepts in my work. Please update me about your new posts

    keep it up good work.

    Thanks

  24. Awesome… thank you so much!!

  25. Ari

    “// Override the createQuestion method it inherited”

    did you mean to say…
    // Override the displayQuestion method it inherited

    BTW, thanks for the awesome explanations backed by appropriate code!!!

  26. Terral Lewis

    Is the Object.create method used in conjunction with the inheritPrototype function or can one or the other be used? Seems to me they virtually do the same thing and if not, could you explain the differences? Thx!

    • Richard Bovell (Author)

      Very good question, Terral.

      The Object.create method basically copies the methods and properties from one object to another, and it returns a new object that inherits from the object you passed into it.

      On the other hand, the inheritPrototype function uses the Object.create method to do the copying of methods and properties, and then it also reset the Constructor and the prototype because the Constructor gets overwritten during the Object.create step.

      So, the direct answer to your question:
      you can use only the inheritPrototype function, since it makes us of Object.create to copy the methods and properties.

  27. Ryan

    Thanks for all this! I have a question:

    I’ve been trying to get the code:

    allQuestions.forEach(function(eachQuestion) {
    eachQuestion.displayQuestion();
    });

    to display all the questions in HTML. If I console.log(questionToDisplay); in the original Question.prototype, everything shows up, but trying a method to get it to display in HTML always results in undefined.

    Any suggestions?

    I really appreciate it. I’m a designer, and your track is the first to really get Javascript to click.

    • Richard Bovell (Author)

      First, thanks very much for helping me fix the issue with the blog blocking comments, Ryan. I really appreciate it.

      Could you post all of your code here or on JSBin so I can see what is causing the error?

        • Richard Bovell (Author)

          There are 2 simple things missing in your code:
          1. In the displayQuestion method, you were not actually returning anything. You commented out the console.log statement, but you forgot to add this:

          
          // You have to return the questionToDisplay variable which has all the question info (HTML plus question text)
          return questionToDisplay;
          

          2. And when you call the displayQuestion method, remember you have to execute it as a function with the parentheses like this:

          
          allQuestions[0].displayQuestion();
          

          You were calling it like a property like this:

          
          allQuestions[0].displayQuestion;
          

          So those two small changes will get your code working.

          One other note: as you will see in your JSFiddle example, the questions are being displayed fine, but they are appended to the HTML document as text. This makes sense because of this line:

          
          document.createTextNode(allQuestions[0].displayQuestion());
          

          You have to modify the displayQuestion method to return the question without the HTML div stuff. You can add the HTML div stuff separately with createElement.

  28. Stefano Pongelli

    Very nice article indeed!

  29. abhishek

    hey, I got the CC/PP, the first part and thought like got the Crockford’s Object.create too the way you explained. But then, I lost it quickly in inheritProperty function.

    var copyOfParent = Object.create(parentObject.prototype);

    //Then we set the constructor of this new object to point to the childObject.
    //This step is necessary because the preceding step overwrote the childObject constructor when it overwrote the childObject prototype (during the Object.create() process)

    why you said that preceding stpe overrworte the childObject contructor when it overwrote the childObject prototype (during the Object.create() process)

    basically the last comment of yours, as I see preceding step is doing nothing with the childObject at all.

    And also might be I don’t get it all. For me
    you should be passing parent Object in Object.create here instead of parentObject.prototype
    var copyOfParent = Object.create(parentObject.prototype);

    lets say in the simplest of scenario, when parentObject is created from literal or new Object() prototype would be Object right? and we don’t get any properties of parentObject at all only Object properties we will get which is nothing.

    Its like in the example just above you gave if you have passed cars.prototype would you have got anything (any property I mean) in toyota?

    • Richard Bovell (Author)

      why you said that preceding stpe overrworte the childObject contructor when it overwrote the childObject prototype (during the Object.create() process)

      Ordinarily, the constructor property of every function points to the constructor of the function. For example:

      function Fruit () {}
      var newFruit = new Fruit ();
      console.log (newFruit.constructor) // Fruit ()
      

      But when we overwrite the prototype like we did in the example code in the article, this happens:

      function Fruit () {}
      Fruit.prototype = {
      myName: function () {
      console.log("My Name function");
      }
      }
      
      // Here, you see that the constructor property no longer points to Fruit ()
      // it has the value of the Object () constructor instead
      var anotherFruit = new Fruit ();
      console.log (anotherFruit.constructor) // Object() 
      

      So, if we want the constructor property to point to the correct constructor, we have to reset it. Thus: this line:

      constructor: User
      

      And also might be I don’t get it all. For me
      you should be passing parent Object in Object.create here instead of parentObject.prototype
      var copyOfParent = Object.create(parentObject.prototype);

      The reason we pass the parentObject.prototype to the Object.create method is because we want the copyOfParent prototype to inherit from the parentObject prototype. The last line is this: childObject.prototype = copyOfParent;

      The prototype properties will not be inherited in the example code you provide.

      Note that you can inherit properties with this:

      var someObj = Object.create (anotherObj);
      

      Or you can inherit the prototype properties like this:

      var someObj.prototype = Object.create (anotherObj.prototype);
      

      lets say in the simplest of scenario, when parentObject is created from literal or new Object() prototype would be Object right? and we don’t get any properties of parentObject at all only Object properties we will get which is nothing.

      Yes, you are correct that the parentObject’s prototype will be the Object () constructor. But parentObject will get some properties because there are many properties and methods that are inherited from the Object prototype.

      These inherited properties and methods that objects inherit from the Object () are constructor, hasOwnProperty (), isPrototypeOf (), propertyIsEnumerable (), toLocaleString (), toString (), and valueOf (). ECMAScript 5 also adds 4 accessor methods to Object.prototype.

      Its like in the example just above you gave if you have passed cars.prototype would you have got anything (any property I mean) in toyota?

      You should understand this now, after you have read my answer to the first part of your question.

      To understand Object.create, know that if we pass in an object, we are inheriting the properties of that object. If we pass in an object prototype, we are inheriting the object prototype like this:

      
      copyOfParent.prototype = Object.create(parentObject.prototype);
      
  30. Dave Rothfarb

    Thank you so much for this fantastically helpful guide! I’m a JavaScript newbie and coming from lower level OOP languages, I need all the help I can get. This is a great site!

    -Dave

  31. Foysal Mamun

    Thank you very much to describe easy way.

  32. Hi! ,i have a question if i want call a function of the same class from other function also of that class, What do I do?.

    for example

    function Myclass(){}

    MyClass.prototype = {
    constructor:MyClass,
    func1:function(){ alert("hello world"); },
    func2:function(){ //call func1 ??? how???? }

    }

    thanks! , very nice post!

  33. Viva Victor

    I enjoyed going through your article, i’ts really good kip it up. A lot of young programmers (like me) are outside looking for someone like you to make us understand more. Thanks!

  34. hey I would swap those two lines, the controctor is getting overridden by the object.prototype. so you always need to put set the constructor at the end.

    function inheritPrototype(childObject, parentObject) {
    var copyOfParent = Object.create(parentObject.prototype);
    childObject.prototype = copyOfParent;
    copyOfParent.constructor = childObject;
    }

  35. Soichi Hayashi

    Thank you for the great article!

    Could I (or should I?) make all inherited functions defined inside the constructor as privileged functions, instead of defining them outside the constructor function using .prototype property? Is there a fundamental difference in the way privileged functions are inherited compared to prototype methods?

    • Reply

Thank you for the g

s="f s="span class="author-tag"> (Author)