Transcript from the "OLOO Questions" Lesson
>> Speaker 2: What if you wanted to delegate B1, for example, to more than one object?
>> Kyle Simpson: There's only one prototype change.
>> Speaker 2: Okay.
>> Speaker 3: So bar cannot have an innate function?
>> Kyle Simpson: Bar doesn't have a constructor. It could have an init I had on the previous slide, bar had an init.
[00:00:24] But really in all truth if you went back to the original code, this is the only constructor code that mattered anyway. So in the final analysis, I moved the init all the way up to foo. Sorry, lots of arrows here. I moved the init all the way up to foo cuz that's the only place we ever cared.
[00:00:40] So when I say B1.init, it delegates all the way up the chain to it. Now, the substance of your question may have also been, can I do this shadowing thing? Can I have multiple objects with the same method, and I would suggest to you if you choose to do shadowing you have all the same problems with all that crappy manual explicit polymorphism thing.
[00:01:00] If you choose behavior delegation then you would make these objects have unique names for their unique tasks. So you wouldn't call it find on two different objects because that is not, that's general names. You'd call it find task and find user, or something like that. And, by virtue of them having different method names, they can easily delegate to each other.
>> Speaker 2: So, there's no more constructors?
>> Kyle Simpson: There's no more constructors. If we need to do initialization tasks, we can have functions that do initialization tasks. There's another thing, by the way, kind of brings up a point. There's another thing, by the way, that people sometimes point out. They say, well you turned one line of code in the previous thing, into two lines of code.
[00:01:42] Despite all the other simplification that I did up here, people still get mad at me that I've forced you to do two lines of code instead of one. My response to that is, in the previous code, you are required to do both your construction and your initialization in one step.
[00:01:58] You have no choice cuz that's what a constructor does. In this piece of code there are two separate steps an they theoretically can happen at two totally different times. For example, you now have the flexibility to create all of your objects in a pool at the beginning but wait until later to initialize them.
[00:02:15] And you didn't have that capability with constructor based coding, so I actually think it's a benefit that they are two separate steps, but they are in fact two separate steps. Yeah. Go ahead Mark.
>> Speaker 4: I was just curious, performance characteristics, if you have an object that has all these methods on init, you create loss for those objects versus you use the prototype.
[00:02:43] Doesn't the prototype perform better because the prototype only has one instance of the method versus an object, you have potentially 100 instances of?
>> Kyle Simpson: We don't, that's the point. What's deceptive here, and you just have to take my word for it, this is the exact same mechanism and functionality, it will have the exact same performance characteristics.
[00:03:07] The only difference is that it's less code to get there. But there's still just one init function on the foo. If I created B1 through B1000, I don't have 1000 inits. I still just have one, because I'm still using delegation. The difference is, I have a lot less code and a lot less complexity to get the same result.
>> Speaker 4: If we create 1,000 bars, wouldn't you have 1,000 speak methods, or would-
>> Kyle Simpson: In that case, yeah. But if I had 1,000 child classes of, if I had bar one through bar 1,000 as 1,000 child classes, I'd have 1,000 bar prototypes. So, yes. In that case, I would.
[00:03:47] But the real question is usually, what if I have a thousand instances.
>> Speaker 4: Yeah, so if you have a thousand instances of, that's holding state for a thousand different objects, you would want their methods to be from another object that it was linked to.
>> Kyle Simpson: That 's usually the design pattern is that your methods are on, your methods are delegated to, but your end leaf nodes are the ones that hold states.
[00:04:17] Your B1 through B1000 would have just your me properties on it.
>> Speaker 4: So then you'd only have one instance for one method for-
>> Kyle Simpson: Generally that's how you would do it.
>> Speaker 4: Yeah, yeah. That's cool.
>> Kyle Simpson: So everything that you're currently doing right now, where you're dot prototypes and your constructors or maybe you're using one of those user lend libraries, I'm not suggesting that you would lose capability.
[00:04:41] I'm suggesting that you can think about the design pattern differently and you can have simpler code. But we haven't lost anything from the previous slides. Yeah.
>> Speaker 3: I have a couple questions coming in here. Oliver K asks, are there real world examples of this Oloo style?
>> Kyle Simpson: Oloo is something I invented recently.
[00:05:22] And what I'm hoping to do is evangelize the concept that there's this other, better way of doing things.
>> Speaker 3: Yeah, another one. Well, Oscar P's asking if you can please explain Object.create. I probably could do that myself.
>> Kyle Simpson: Yes, I will show you the Object.create, because every magician has a way that they do the trick.
[00:05:44] I will show you Object.create in just a second.
>> Speaker 5: Can you quickly summarize what the main push back you get when you push this to people who come in to the class velocity? Is there a common, but this the kind of-
>> Kyle Simpson: Yeah yeah.
>> Speaker 5: the main contention point?
>> Kyle Simpson: Yeah, that's a great question. So I expound amazingly long detail and length in the book, and I recommend reading the this and objects prototype book. Chapters four, five, and six of that book are all about what we've just discussed, and I lay out the full case, but the primary push back that people give me is, but classes are how we've been taught to design things.
[00:06:51] So, it's just a different design pattern, but the primary push back I get from people is, but, no. There's certain problems that require classes, and I say, no. There's a really interesting paper that I just recently read. I'll try to maybe find it and put the link in the chat I'm sure I tweeted about it, but it talks about, if you actually go back and look at the way the real world works this whole concept of classification is actually somewhat unnatural, because classifications don't really work.
[00:07:19] And delegation, this prototype mechanism is actually a lot more of a natural thing. But we've spent all our careers being told that classes are the way to design proper software. So that's the biggest push back is people don't want to change their thinking.
>> Kyle Simpson: All right so, we have this b1 bar and foo and I promised you simpler code.
[00:07:41] Hopefully you can see ostensibly that there's a lot less complexity to what we're managing in the code. But that's not the only story, so I want to go back to the old and busted form. This was with the B1 and B2s in it. This is the old and busted form and remember the old and busted diagram.
[00:07:56] Here's the new hotness. This is Oloo style code, and here's the big money shot, the payoff, because here's the new mental model that you need to keep in mind.
>> Kyle Simpson: That's it, cuz all we care about is the objects and their relationships to each other. We don't care about constructors, we don't care about these indirect creations of things.
[00:08:17] We just directly create the objects and directly create the relationships. That's all we ever cared about anyway.
>> Kyle Simpson: So any good magician doesn't wanna tell you how he does his trick. How does Object.create work? This is the polyfill for object create in pre es five. Look at that.
[00:08:34] We've got functions and prototypes and new constructors. We took all of that crap out of our code and hid it inside of a nice clean utility.