Transcript from the "OLOO" Lesson
>> Kyle Simpson: I showed you the complex way, the way everybody's been trying to do it for 20 years. I'm now gonna perform a magic trick. I'm gonna take that complicated code and I'm gonna simplify it. And I'm gonna show you how we can get the same behavior, the exact same functionality.
[00:00:19] Without all of that extra croft and confusion. Okay. Now that's a tall order, but I'm gonna perform this magic trick in the next couple of minutes, okay. And what I'm going towards is I needed to come up with a name for something to contrast with OO, with object oriented with class oriented coding, and I came up with this phrase OLOO.
[00:01:00] To get us at these three objects linked to each other. Should we just create those objects without the distraction and get the same benefits. And that's what I'm going to do. In fact, what I'm going to do is derive over several slides how we get to what I call OLOO style code that is object only linked, objects linked to other objects only.
[00:01:22] How do we get to OLOO style code? And the interim steps are gonna look a little weird. So, you gotta just bear with me. But what I want you to do, you know how magicians, the way they perform their tricks is they distract you over here so they can perform their trick over here.
[00:01:37] I'm gonna do the reverse. I'm gonna tell you to look for and what I want you to keep your eye on is that object, that object and that object. Don't get distracted by all the other stuff. Pay only attention to the objects, cuz they're the only things we cared about anyway, okay?
[00:01:52] The first thing I wanna do to simplify this code is I need to get rid of any kind of reference to a constructor, like new Bar. That's class oriented thinking. It's more complex. It's more mentally taxing. We gotta get rid of it. So this line 17, I'm gonna change line 17 to not deal with a new constructor.
[00:02:10] Okay? Ready? Here we go. Now line 17 has become two lines, which temporarily is going to look worse, but you just gotta bear with me on these intermediate forms. We now are using a utility called object.create, which I already showed you before I make a b1 object that is linked to the Bar prototype object, which is what we want.
[00:02:29] And then I temporarily have to manually call that Bar function with b1 as my context. Okay? So temporarily this looks kind of ugly but it'll get better. At least we've gotten rid of the new keyword; we're not doing class instantiation anymore. We're just making objects linked. Okay? And now I remind you that we still have a b1 linked to a Bar.prototype linked to a Foo.prototype.
[00:02:55] This code does exactly the same thing as the previous code, same capability. Okay. Now the next step of my magic trick is I wanna get rid of any references to these .prototypes that are here. This .prototype, gotta get rid of that reference. All these .prototypes over here. This function constructor, I've gotta get rid of all that cuz that's way too confusing.
[00:03:14] Okay. Everybody ready? All right, now, I called it capital B just because of consistency sake, but it's not a constructor any more, it's just an object. We have a Bar object that we can add methods directly to it, there's no .prototype preferences or anything, we're just putting properties directly on objects.
[00:03:36] And look down here, look how much more simpler this got. Cuz now all I do is say object.create bar. I just link b1 directly to Bar. Instead of linking it to a .prototype or some constructor or some other confusing thing, I just link b1 directly to Bar. So I use my little utility object create to do my linkages, and object create becomes the hero of the party because he does what we need without all that other confusing crap going on.
[00:04:01] And we still end up with b1 linked to bar linked to foo.prototype. Is everybody following so far? Final step of the magic trick, okay? I've got to get rid of all of these references to foo.prototype and function foo constructor. Got to get rid of all of that. Everybody ready?
[00:04:20] Bam. Now foo itself, is just an object. That has methods directly on it. Bar is just an object with methods directly on it. And b1 is just an object that is linked to bar. So we still have in the final tally, a object, linked to another object, linked to another object.
[00:04:43] We have all the same capability as three slides ago. The fact that they can delegate to each other, and the fact that we can setup multiple delegations, and all of that stuff. We have all the same capability, but what we have now done is gotten a syntax that has completely removed any relationship to the class-oriented thinking.
[00:05:02] These are just peer objects that delegate to each other, that's all it is. As a quick example, and I talk about this in my book, This and Object Prototypes, book that I've written, I talk about all this stuff and as a quick example, you think about a login controller and an authentication controller.
[00:05:18] Your login controller is a peer object to your authentication controller. It's not one is the parent and one is the child. They're peer objects. One of them handles managing your login form, and one of them handles making AJAX calls to the server to find out if the password was correct.
[00:05:33] They're two peers to each other. And one of them needs to delegate to the other so that the entire task of getting you logged in can complete. So the login controller delegates to the authentication controller. It's a different way of thinking. Instead of orienting your code with parents and children and overloading and polymorphism and all that stuff that you've been trained on for 20 years.
[00:05:56] You think in terms of this simple objects delegating to other objects. Like B1 delegating to bar delegating to foo. As an example for instance you could have [COUGH] foo as a general utility object that a bunch of different objects can delegate to. And utility methods like loggers and other things are, you delegate to the utility object to use it.