I am new to JavaScript OOP. Can you please explain the difference between the following blocks of code? I tested and both blocks work. What's the best practice and why?
First block:
function Car(name){ this.Name = name; } Car.prototype.Drive = function(){ console.log("My name is " + this.Name + " and I'm driving."); } SuperCar.prototype = new Car(); SuperCar.prototype.constructor = SuperCar; function SuperCar(name){ Car.call(this, name); } SuperCar.prototype.Fly = function(){ console.log("My name is " + this.Name + " and I'm flying!"); } var myCar = new Car("Car"); myCar.Drive(); var mySuperCar = new SuperCar("SuperCar"); mySuperCar.Drive(); mySuperCar.Fly();
Second block:
function Car(name){ this.Name = name; this.Drive = function(){ console.log("My name is " + this.Name + " and I'm driving."); } } SuperCar.prototype = new Car(); function SuperCar(name){ Car.call(this, name); this.Fly = function(){ console.log("My name is " + this.Name + " and I'm flying!"); } } var myCar = new Car("Car"); myCar.Drive(); var mySuperCar = new SuperCar("SuperCar"); mySuperCar.Drive(); mySuperCar.Fly();
Why did the author add the Drive
and Fly
methods using prototype
, and did not declare them as a this.Drive
method inside the Car
class and as this.Fly
in the SuperCar
class?
Why does SuperCar.prototype.constructor
need to be set back to SuperCar
? Is the constructor
property overridden when prototype
is set? I commented out this line and nothing changed.
Why call Car.call(this, name);
in the SuperCar
constructor? Won't properties and methods of Car
be 'inherited' when I do
var myCar = new Car("Car");
To add to Norbert Hartl's answer , SuperCar.prototype.constructor isn't needed, but some people use it as a convenient way of getting the constructing function of an object (SuperCar objects in this case).
Just from the first example, Car.call(this, name) is in the SuperCar constructor function because when you do this:
var mySuperCar = new SuperCar("SuperCar");
This is what JavaScript does:
Notice how JavaScript didn't call Car for you. Prototypes being as they are, any property or method that you don't set yourself for SuperCar will be looked up in Car. Sometimes this is good, eg SuperCar doesn't have a Drive method, but it can share Car's one, so all SuperCars will use the same Drive method. Other times you don't want sharing, like each SuperCar having it's own Name. So how does one go about setting each SuperCar's name to it's own thing? You could set this.Name inside the SuperCar constructor function:
function SuperCar(name){
this.Name = name;
}
This works, but wait a second. Didn't we do exactly the same thing in the Car constructor? Don't want to repeat ourselves. Since Car sets the name already, let's just call it.
function SuperCar(name){
this = Car(name);
}
Whoops, you never want to change the special this
object reference. Remember the 4 steps? Hang onto that object that JavaScript gave you, because it's the only way to keep the precious internal prototype link between your SuperCar object and Car. So how do we set Name, without repeating ourselves and without throwing away our fresh SuperCar object JavaScript spent so much special effort to prepare for us?
Two things. One: the meaning of this
is flexible. Two: Car is a function. It's possible to call Car, not with a pristine, fresh instantiated object, but instead with, say, a SuperCar object. That gives us the final solution, which is part of the first example in your question:
function SuperCar(name){
Car.call(this, name);
}
As a function, Car is allowed to be invoked with the function's call method , which changes the meaning of this
within Car to the SuperCar instance we're building up. Presto! Now each SuperCar gets it's own Name property.
To wrap up, Car.call(this, name)
in the SuperCar constructor gives each new SuperCar object it's own unique Name property, but without duplicating the code that's already in Car.
Prototypes aren't scary once you understand them, but they're not much like the classic class/inheritence OOP model at all. I wrote an article about the prototypes concept in JavaScript . It's written for a game engine that uses JavaScript, but it's the same JavaScript engine used by Firefox, so it should all be relevant. Hope this helps.
The two blocks differ in a way that in the first example Drive()
will only exist once while at the second approach Drive()
will exist per instance (Every time you do new Car()
the function drive()
will be created again). Or different said the first uses the prototype to store the function and the second the constructor. The lookup for functions is constructor and then prototype. So for your lookup of Drive()
it finds it regardless if it is in the constructor or in the prototype. Using the prototype is more efficient because usually you need a function only once per type.
The new
call in javascript automatically sets the constructor in the prototype. If you are overwriting the prototype so you have to set the constructor manually.
Inheritance in javascript has nothing like super
. So if you have a subclass the only chance to call the super constructor is by its name.
Norbert, you should note that your first example is pretty much what Douglas Crockford calls pseudoclassical inheritance. Something things to note about this:
Lastly, I'd like to mention that I have several examples of TDD JavaScript Inheritance code that works here: TDD JavaScript Inheritance Code and Essay I'd love to get your feedback as I'm hoping to improve it and keep it open source. The goal is to help classical programmers get up to speed with JavaScript quickly and also supplement the study both Crockford and Zakas books.
function abc() {
}
Prototype methods and property created for function abc
abc.prototype.testProperty = 'Hi, I am prototype property';
abc.prototype.testMethod = function() {
alert('Hi i am prototype method')
}
Creating new instances for function abc
var objx = new abc();
console.log(objx.testProperty); // will display Hi, I am prototype property
objx.testMethod();// alert Hi i am prototype method
var objy = new abc();
console.log(objy.testProperty); //will display Hi, I am prototype property
objy.testProperty = Hi, I am over-ridden prototype property
console.log(objy.testProperty); //will display Hi, I am over-ridden prototype property
http://astutejs.blogspot.in/2015/10/javascript-prototype-is-easy.html
我不是100%肯定,但我相信不同之处在于第二个示例只是将Car类的内容复制到SuperCar对象中,而第一个示例将SuperCar原型链接到Car类,因此运行时更改为Car类也会影响SuperCar类。
There are several questions here:
Can you please explain the difference between the following blocks of code. I tested and both blocks work.
The first only creates one Drive
function, the second creates two of them: one on myCar
and another one on mySuperCar
.
Here is code that would give different results when either the first or second block was executed:
myCar.Fly === mySuperCar.Fly // true only in the first case
Object.keys(myCar).includes("Fly") // true only in the second case
Object.keys(Car.prototype).length === 0 // true only in the second case
What's the best practice and why?
Why did the author addDrive
andFly
methods usingprototype
, but doesn't declare them asthis.Drive
method insideCar
class andthis.Fly
inSuperCar
class?
It is better practice to define methods on the prototype, because:
Object.create(Car.prototype)
); Why does
SuperCar.prototype.constructor
need to be set back toSuperCar
? Isconstructor
property overridden whenprototype
is set? I commented out this line and nothing changed.
The constructor
property is not overridden when prototype
is set. But the constructor of new Car()
is Car
, so if you set new Car()
to SuperCar.prototype
, then obviously SuperCar.prototype.constructor
is Car
.
As long as you don't reassign to prototype
, there is an invariance: Constructor.prototype.constructor === Constructor
. For example, this is true for Car
: Car.prototype.constructor === Car
, but it is equally true for Array
, Object
, String
, ...etc.
But if you reassign a different object to prototype
, that invariance is broken. Usually this is not a problem (as you have noticed), but it is better to reinstate it, because it answers the question "Which constructor uses this prototype object when creating new instances?" Some code may do such inspection and depend on it. See "Why is it necessary to set the prototype constructor?" for such cases.
Why call
Car.call(this, name);
inSuperCar
constructor? Won't properties and methods of Car be 'inherited' when I dovar myCar = new Car("Car");
If you don't do Car.call(this, name);
then your SuperCar
instance will not have a name property. You could of course decide to just do this.name = name;
instead, which just copies the code that is in the Car
constructor, but in more complex situations it would be bad practice to have such code duplication.
It would not be helpful to call new Car(name)
within the SuperCar
constructor, as that will create another object, while you really need to extend the this
object. By not using new
(using call
instead) you actually tell the Car
function to not run as a constructor (ie to not create a new object), but to use the object you pass to it instead.
In modern versions of JavaScript you can use super(name)
instead of Car.call(this, name)
:
function SuperCar(name) {
super(name);
}
Today, you would also use the class
syntax and write the first code block from the question as follows:
class Car { constructor(name) { this.name = name; } drive() { console.log(`My name is ${this.name} and I'm driving.`); } } class SuperCar extends Car { constructor(name) { super(name); } fly() { console.log(`My name is ${this.name} and I'm flying!`); } } const myCar = new Car("Car"); myCar.drive(); const mySuperCar = new SuperCar("SuperCar"); mySuperCar.drive(); mySuperCar.fly();
Note how you don't even have to mention the prototype
property to achieve the goal. The class ... extends
syntax also takes care of setting the prototype.constructor
property as the first block in your question did.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.