0

In the following example, the Bird constructor defines two properties: name and numLegs:

function Bird(name) {
  this.name = name;
  this.numLegs = 2;
}

let duck = new Bird("Donald");
let canary = new Bird("Tweety");

name and numLegs are called own properties, because they are defined directly on the instance object. That means that duck and canary each has its own separate copy of these properties. In fact every instance of Bird will have its own copy of these properties.

Since numLegs will probably have the same value for all instances of Bird, you essentially have a duplicated variable numLegs inside each Bird instance.

This may not be an issue when there are only two instances, but imagine if there are millions of instances. That would be a lot of duplicated variables.

A better way is to use the prototype of Bird. Properties in the prototype are shared among ALL instances of Bird. Here's how to add numLegs to the Bird prototype:

Bird.prototype.numLegs = 2;

Now all instances of Bird have the numLegs property.

console.log(duck.numLegs);
console.log(canary.numLegs);

My Question: "This may not be an issue when there are only two instances, but imagine if there are millions of instances. That would be a lot of duplicated variables."

What is the issue with having duplicated variables? Is it that they take up memory? And does it slow your program down?

Thanks in advance :)

Sugarpearl
  • 95
  • 6
  • 1
    "but imagine if there are millions of instances" ... this is where one would make it an *array* of instances. Beside each time you call `new` those are distinct instantiations, so I dont know what you mean by "duplicated variables". – mardubbles Apr 16 '22 at 04:06
  • 1
    @mardubbles That has nothing do to with the properties, you'll still have the property duplicated in every one of them. – Barmar Apr 16 '22 at 04:07
  • 1
    The only issue is that they take up memory. On the other hand, it's faster to access a property in the object than search the prototype chain. So it's a tradeoff. – Barmar Apr 16 '22 at 04:07
  • 1
    Ahh I see, but even still, if an object could have "numLegs" property if it differered from a default, how to make one not have "numLegs" if it didn't differ? You could do that. But just not with `new` on a "class". – mardubbles Apr 16 '22 at 04:11
  • 1
    Normally we don't worry about small properties like a number being duplicated. But large properties like method functions are usually stored in the prototype. – Barmar Apr 16 '22 at 04:11
  • 1
    It's possible for an individual instance to have its own `numLegs` property, this will override the one from the prototype. This is useful for exceptions to the general case. – Barmar Apr 16 '22 at 04:12
  • 1
    E.g. `Mammal.prototype.has_bill = false; platypus.has_bill = true;` – Barmar Apr 16 '22 at 04:13
  • @Barmar Thank you so much for your response. Are you saying it's better to store properties that will be similar across all instances in the prototype so that the property in the individual instances won't override the one in the prototype by accident? And by doing so you also free up more space in the memory, but the tradeoff is that it is slightly slower to access the property since you have to search up the prototype chain? Let me know if my understanding is off. Thank you! :) – Sugarpearl Apr 16 '22 at 04:21
  • 1
    We normally decide this based on the semantics of the property. A property that could be different between instances is usually an instance property, something that's defined to be the same for the entire class is a class property. While it's possible to do what I said above with a general class property and per-instance exceptions, it's more confusing and isn't common. – Barmar Apr 16 '22 at 04:23
  • 1
    The time-space tradeoff isn't usually a concern because memory is cheap and it's not usually enough to make difference. – Barmar Apr 16 '22 at 04:24
  • So it doesn't really matter whichever way I choose to define my property, at least it won't make that much of a difference to matter? Thanks again. – Sugarpearl Apr 16 '22 at 04:28
  • 1
    That's the power of a prototype based languages, they perform and scale really well. Prototypes are really cheap and as you noticed you don't have to care of the number of instances that you create, since they all will refer to the same prototype. Will you notice the difference in a normal usage scenario ? No you won't. Anyway that's a good practice, that's why you don't write anymore constructor functions like that, but you use ES6 classes where the methods that you declare end up in the prototype of the class itself. – Cesare Polonara Apr 16 '22 at 05:15
  • @CesarePolonara Hey, I remembered you! You helped me with my other question. Thanks again for helping with this one! It's a pain learning all this by yourself and I always appreciate all the help I got! – Sugarpearl Apr 16 '22 at 05:20

0 Answers0