Why use Object.create instead of new Super while assigning DerivedClass.prototype

Question

I've been reading MDN guide on Object Oriented programming with Javascript where in an example to show Inheritance, the following is mentioned:

// Create a Student.prototype object that inherits from Person.prototype.
// Note: A common error here is to use "new Person()" to create the
// Student.prototype. That's incorrect for several reasons, not least 
// that we don't have anything to give Person for the "firstName" 
// argument. The correct place to call Person is above, where we call 
// it from Student.
Student.prototype = Object.create(Person.prototype); // See note below

I've looked into other answers as well, but they don't specifically tell what problems one will face on using Student.prototype = new Person()

One problem mentioned above concerns with passing firstName, but that's just one scenario.

Before anyone marks this as duplicate. The question here Using "Object.create" instead of "new" deals with generally using Object.create instead of constructors and not with what I'm asking.

The question here What is the reason to use the 'new' keyword at Derived.prototype = new Base deals with difference between foo() and new foo()

One answer for this question JavaScript inheritance: Object.create vs new gives one more reason:

When SomeBaseClass has a function body, this would get executed with the new keyword. This usually is not intended - you only want to set up the prototype chain. In some cases it even could cause serious issues because you actually instantiate an object, whose private-scoped variables are shared by all MyClass instances as they inherit the same privileged methods. Other side effects are imaginable.

So, you should generally prefer Object.create. Yet, it is not supported in some legacy browsers; which is the reason you see the new-approach much too frequent as it often does no (obvious) harm. Also have a look at this answer.

Reading the above it seems it depends more on the given scenario being tackled. Is there a stringent reason for MDN saying using new SuperClass() is incorrect?

Depends on your definition of "incorrect". I can't think of a situation where it would be useful, and as others have pointed out there are several reasons why it's problematic. What is your question exactly? Why are you worried about this? — , Nov 24 '15 at 11:30
I'm not worried about it. It's just that most of the JavaScript code that I've seen uses the `new Parent()`. I could see where `Object.create` would be more useful but it doesn't feel right to say the former is plain right incorrect. — Kartik Anand, Nov 24 '15 at 11:47
@KartikAnand: The `new Person` way is usually used by people who haven't really thought it through. It was used in simple code early on and became established, even though it's a real pain to do right. It *can* be correct, it's just over-complicated in the general case. So when we'd progressed a bit further, we realized there was a better way. I've explained that more thoroughly in my updated answer. — T.J. Crowder, Nov 24 '15 at 11:59
Possible duplicate of [Benefits of using `Object.create` for inheritance](https://stackoverflow.com/q/17392857/1048572) — Bergi, Aug 10 '21 at 14:54

T.J. Crowder · Accepted Answer · 2015-11-24T11:51:39.383

TL;DR You could use new Person to build your Student.prototype, but doing so complicates all of your constructor functions, limits their ability to detect construction errors, and requires that all constructors everywhere handle that form of use. Since it's more complicated, error-prone, and limiting, most people have gone the other way: Object.create.

The main pragmatic issue is: What if the super constructor requires arguments? Say Person requires a name:

function Person(name) {
    this.name = name;
}

How am I to use new Person to create my prototype? I have no name to provide it.

Now, there are two ways to solve this:

Require that all constructors that need arguments detect that they have been called without arguments, assume they're being called to build a prototype, and handle that case correctly.
Use Object.create instead.

Here's the first way:

// NOT WHAT MOST PEOPLE DO
function Person(name) {
    if (arguments.length === 0) {
        return;
    }
    this.name = name;
}
function Student(name) {
    Person.call(this, name);
}
Student.prototype = new Person;
Student.prototype.constructor = Student;

Note how Person has to detect that it's being called with no arguments, hope that that's because it's being used to create a prototype rather than for some other reason, and avoid trying to use the missing arguments.

That's error-prone and awkward, and it means that Person can't (for instance) raise an error if it doesn't receive name for the final instance construction call. It just doesn't know why it's being called, so it can't tell whether not having name is correct or not.

So most people go the other way:

// What most people do
function Person(name) {
    this.name = name;
}
function Student(name) {
    Person.call(this, name);
}
Student.prototype = Object.create(Person.prototype);
Student.prototype.constructor = Student;

Person doesn't have to have any special-case code in it, and is free to raise an error if it doesn't get name and needs it.

That's sufficienly ingrained now, as well, that it's baked into ES2015 (aka ES6)'s class keyword. This ES2015 code:

class Student extends Person {
    constructor(name) {
        super(name);
    }
}

Translates fairly closely to the Object.create ES5 code above. (Not exactly, but fairly closely.)

Why use Object.create instead of new Super while assigning DerivedClass.prototype

1 Answers1