This course has been updated! We now recommend you take the Deep JavaScript Foundations, v3 course.

Check out a free preview of the full Advanced JavaScript course:
The "Quiz: Prototype Unit" Lesson is part of the full, Advanced JavaScript course featured in this preview video. Here's what you'd learn in this lesson:

Kyle presents a quiz about the prototype unit.

Get Unlimited Access Now

Transcript from the "Quiz: Prototype Unit" Lesson

>> [MUSIC]

>> Kyle Simpson: How is JavaScript's Prototype chain not like traditional/classical inheritance? What's the key difference?
>> Speaker 1: It doesn't copy, it links.
>> Kyle Simpson: It doesn't copy, it links. The errors go in the opposite direction. What does behavior delegation mean and how does it describe the object linking that exists in JavaScript?

>> Speaker 2: A new object delegates behaviors to its prototype and any object made from the same constructors shares the same prototype?
>> Kyle Simpson: I like the first thing you said. I don't like the second thing you said that much cuz you're talking about constructors. But yes, objects delegate up the chain.

[00:00:45] So any time we call a property or method on one object, and he can't handle that property or method, he delegates up his prototype chain to another object. What that object happens to be is arbitrarily either simple or complex depending on which style of code you like to write.

[00:00:59] But the fact of the matter is that objects delegate to each other.
>> Kyle Simpson: Why is behavior delegation as a design pattern, really what I mean is why is this, not OLOO, I mean delegation, what is the benefit of the delegation design pattern?
>> Speaker 3: You don't have copies of the function.

>> Kyle Simpson: You don't have copies of the function. So let me state it this way cuz that might be a little bit abstract of a question for me to ask at this point in our discussion, so let me answer my own question. With delegation we are embracing the fact that all objects continue to exist and they are dynamically and changing, and the linkage that occurs is a dynamic linkage at runtime.

[00:01:47] With classes, there's a snapshot copy that occurs. So once I've made this copy, then if I change the parent class in some way, it's not affecting the child. But with JavaScript and really with embracing the delegation design pattern, we embrace the idea that foo can change during the runtime, and bar automatically now gets to delegate to a changed foo because it's a live link.

[00:02:10] So it actually is a much more powerful mechanism. As a matter of fact, it's been said, and I agree, delegation is more powerful than class because you can implement classes in delegation, but you cannot do the reverse. You can't implement delegation in a class mechanism.
>> Kyle Simpson: What are the tradeoffs to the prototype mechanism?

>> Speaker 2: They're never gonna add method missing to JavaScript.
>> Kyle Simpson: They are actually adding it, it's called proxy.
>> Speaker 2: Shit.
>> Kyle Simpson: [LAUGH] That's gotta be '06.
>> Speaker 3: You can't shadow your-
>> Kyle Simpson: That's one of the downsides to the way the mechanism works in JavaScript, is that shadowing is kind of awkward.

[00:02:52] Now there's some, debatably, depending on your perspective, ES6 actually adds a class keyword and they add a super keyword, and so they're even further going down the bad path that I think we shouldn't be going down. But they've tried to syntactically solve some of those issues, not all of them.

[00:03:10] But you're right, shadowing is still kind of an awkward thing. But one of the downsides to delegation is that, whether it's delegation the way I've shown it, or whether it's the old class prototype style of delegation, everything's public. Which means you don't get any private state, you lose all the capabilities of encapsulation.

[00:03:29] So modules are nice because you get to encapsulate private state, but prototypes lose that. Prototypes are nice because there's only one copy of a method and if you create a whole bunch of instances, you've got less memory usage. So there's these tradeoffs that happen between the two. In reality, I've been in the industry now 15 or 16 years, and every one of the jobs I've ever had, I would see these code bases with these fantastically complex five level deep hierarchies of inheritance with specialization and all this overloading and all this stuff.

[00:04:01] And then when it got down to it at the very end, the very leaf node, they just created one instance of something. And I know you laugh at that, but it's ridiculous how often that happens, that we go to all this trouble to create the classes because that's how we were told to design software, but in reality we don't take any advantage of it at all.

[00:04:21] We go to create all these hierarchies and then we just instantiate one of them. Well if you're just gonna instantiate one of them why didn't you just do a single flat level module? Why create all of that extra complexity of software design? [COUGH] So it was asked in the chat and I'll expound upon it, 95% of the time when I design software, I use the module pattern.

[00:04:40] Because I'm not creating multiple instances so it's not a big deal that there might be two copies of the methods or something. And the other 5% of the time, when I do choose to use delegation, I use OLOO style rather than the constructor prototype style.
>> Speaker 4: So if you use the module pattern for 95% of your code, how do you handle managing state with 100 objects?

>> Kyle Simpson: I very rarely have 100 objects. It's just not that common in real world JavaScript code. We think in theory, yeah, I'll instantiate this thing, I'll have 100 calendar widgets on a page, but in reality, we never actually have more than just 1. It just comes down to if you really did have a case that you legitimately wanted 100 copies of a thing, then use delegation, but it just doesn't happen very often for me in the real world.

>> Speaker 4: I work on a lot of interfaces, so with complex interfaces, you might have 50 or-
>> Kyle Simpson: What would you have 50 of in a complex interface?
>> Speaker 4: Well in the case of the builder that I'm working on now there's gonna be five or six or seven.
>> Kyle Simpson: Of what?

>> Speaker 4: Of an item, which is a blueprint item.
>> Kyle Simpson: Uh-huh.
>> Speaker 4: Then within that item there's lots of joinable edges that each have a state.
>> Kyle Simpson: So if you did actual benchmarking of the performance downside, you might say to yourself, it's terrible that I'm copying the method seven times.

[00:06:23] In reality, you would have to be creating hundreds and hundreds of objects before the optimizations that the engine is already doing couldn't keep up. So if you're just doing five or seven of them, I still think modules would probably suffice, but-
>> Speaker 4: Yeah, there could be 50-
>> Kyle Simpson: I think you would literally have to have like 500 or more before you could convince me you really have to go with the delegation pattern, but that's just me.

[00:06:51] Honestly, five or seven of them I wouldn't even blink in using modules.
>> Speaker 4: Even if one item has 100 methods, or 50 methods?
>> Kyle Simpson: Yeah, the JavaScript engine is just so good at optimizing this stuff, it's just not gonna really matter in the real world, unless you get to a really large scale of number of instances, and I just don't see that very often.