Transcript from the "Quiz: Prototype Unit" Lesson
>> Speaker 1: It doesn't copy, it links.
>> 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: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?
>> 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-
[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?
>> 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?