This course has been updated! We now recommend you take the JavaScript: The Hard Parts, v2 course.

Check out a free preview of the full JavaScript: The Hard Parts course:
The "OOP Exercise, Part 6" Lesson is part of the full, JavaScript: The Hard Parts course featured in this preview video. Here's what you'd learn in this lesson:

With help from the students, Will demonstrates OOP approach using syntactic sugar approach and discusses the benefits.

Get Unlimited Access Now

Transcript from the "OOP Exercise, Part 6" Lesson

>> Class user has a function at the top, the first one, which is just the functionality version of user that we did earlier that creates inside of an empty object, whatever. That's this bit here and we rename that portion of it. We rename it what Katie? Can you see what it says we rename it?

[00:00:16] What did we name that bit that previously was just a regular function? What did we name that bit?
>> The constructor?
>> Constructor. So we rename this bit, I don't know why, constructor. I mean, I do know why, but we rename that bit constructor. And rather than having to manually populate the --set of shared functions that the objects that get returned out of calling user get a bond to.

[00:00:41] Rather than manually populating them, Griffin, what do we do instead? We just announced that it's functions there. We just say, but all that's doing when we announce those two functions, is actually, under the hood, saying user.prototype centered to increment, user.prototype centered to login-- That's literally doing exactly the same thing.

[00:01:04] So we're just going to walk through it to make sure it's really clear. Lindsey, what's the top line telling you to do?
>> Carry a function.
>> The very top line.
>> Declaring a-
>> Class. A class, I'm gonna call it a class I guess. And it has two parts to it, what's the first part tell it to do?

[00:01:28] We go straight in and do this stuff immediately. What's the first part tell us to do, Lindsey?
>> Run a constructor.
>> Well not run, create.
>> Create.
>> So at this point There it is. It's given the label constructor which means now we can specifically say, when I call user I'm calling this bit the constructor portion of it.

[00:02:07] But we can see it's absolutely identical, okay. And then we get to just lift off the functions that we want to get stored in the user.prototype. We don't even do commas between them you just list them off.
>> And what's the first one say, Lindsey?
>> Increment.
>> Increment, which gets stored automatically because this new syntax class says store it increment in the user.prototype.increment.

[00:02:32] There it is. And then login gets stored, user.prototype.login. And at the end of that block, you've achieved exactly the same thing in practice as we did in solution three. But, it is a little bit more like our python or other languages where we've listed all of our functions that are gonna be shared by the resulting objects that come from running user.

[00:02:54] But, it's all a mask. It's all a mask for how JavaScript's actually working under the hood. Under the hood, it's doing all of this, and it's important. There's levels of under the hood we wanna reach. There's levels that we don't wanna reach. There's levels where we don't need to go that deep because.

[00:03:15] Doing so doesn't help us write cleaner, better code, easier to debug, more efficient. We just don't need to know most of the time. This is a level we do need to know. if we don't realize that when we are doing this. If we think when we come to JavaScript coming from Python, that the is behaving the same as [SOUND] Python, we're gonna get incredibly upset when we discover that, actually, under the hood We have this prototype prototype property that has a bunch of shared function on it, and that's actually where our functions are.

[00:03:45] We're gonna get very upset when we try and understand what's happening inside the core to user with a new keyword, and it's saying this. What is this, it's this auto created object, well we want to change the product. How do we do that?
>> None of it's going to work the way we expect from other languages because it's wrapping up a prototypal language.

[00:04:07] Jobs are inherently a typal language. It does not behave in the typical classical style that is known from other languages. And yet, we didn't know that I guess. Maybe we do? But now. Benefits, this approach, this final version, this solution four emerging as the new standard. Feels more like the sound of other languages like Python.

[00:04:33] It emulates very closely. Problems. Not even 99%, 99.9% of developers have no idea how it works, and that means it's hard to debug but its also every senior, or every VP of engineering, every senior developer's favorite itnerview question for mid and senir developers, how is the new keyword working?

[00:04:54] Well, man, one of our favorite problems is a set of codesmith in the first couple of weeks, is rebuild the new keyword for us. We have everything. We can rebuild the new keyword. We wouldn't rebuild it that way, but we can create a function that achieves the same as a new keyword, no problem now.

[00:05:13] Because we know every single piece. Solution two was just bundled up, wrapped up, given some fancy automatons by solution three, just automated bunch of, got rid off bunch of stuff, automated it with a new keyword, these it is. And then solution four said, even that was too long winded.

[00:05:38] Let's make it even easier. Now, to find me a clause, I'll put increment and login in the prototype in user dot prototype. I'll put it in their for you. Just list them off there. I'll o it for you.