JavaScript: The Hard Parts OOP Exercise Q&A and Pair Programming

Transcript from the "OOP Exercise Q&A and Pair Programming" Lesson

[00:00:00]
>> Will Sentance: We've achieved our goal, though, or have we? We've achieved our basic goal that we've bundled up our functions that can be used on the user data in one user object, user1, user2, user. Who can see, though that while this approach fundamentally solves our basic problem of is my functionality gonna be available on my data, when I need it.

[00:00:22] Wherever I pass that user2 object, the functionality increment is available on it. Wherever I pass a user1, by the way, there could be 1,000 user objects. User 400, user 1,000, there could be 1,000 functions. I can know safely in this model that if I do user2002.displayavatar. Whatever of the hundreds of function that use in this function, I'll know, don't worry, it will be there.

[00:00:48] So, I have achieved that goal which we said is a fundamental goal. Anyone see any issue with this approach? Yeah, Dave.
>> Dave: If you're gonna update the functionality, you have to go and-
>> Will Sentance: Yeah, that's a good one, that's a really good one. So maintenance of this is a bit of a pain, right?

[00:01:07] Because I can't go adding to all my user objects because I've already generated them, and they were created inside of this individual function. Andrew, what do you see as a problem?
>> Andrew: If you have thousands of users, you have to have different variable names for everyone?
>> Will Sentance: Okay, that's sort of inherent cuz you're appointed different labels.

[00:01:27] Now can store them in an array or something like that, but ultimately they're all gonna have their own space for their own data. What do you think, Griffin?
>> Griffin: Any functions that then would call those user functions its sends it user1, it's not generic enough just to be able to call it end user.

[00:01:43] You'd have to make it function for each user.
>> Will Sentance: You're getting so close there, right? So you're saying something like this increment function is a new version for every single. But the problem with that is not my genericness, the problem with that is suppose I have 1000 functions that are being declared inside of what I call user creator, get attached to the new user and then get stored in user1.

[00:02:10] This is another brand new user object with all those functions again. All my data is unique in each user, but this functionality is increment function here, so doesn't need to be a brand new version versus this one. What about over 1,000 functions each one with 100 licence code in them and then a 1,000 users, I'm getting a 1000 times by 100 times 1,000 in the lines of code just to describe the same functions.

[00:02:35] If I have a 1000 functions I wanna be able to use on my users and I copy them across every single user that's filling in memory. That's saying declare this function, store in the user, this is an actual copy of the function increment that's attached to the user object.

[00:02:52] If there's a 1000 of those functions, and then on here, an actual brand new copy of that function increment is actually user1. Griffin, is that gonna be good on my memory? That is absolutely unusable. This approach may be simple, it's simple, but it has a fundamental problem. Each time we create a new user, we make space in our computers memory for all our data.

[00:03:17] And functions, data no problem, yeah like name, will, score, three I've got a brand new space in memory for name, will, score, three. Name, team, score, five. But my functions they are the same on every single object user1, user2, user400, user1000. Why are they making copies? Our functions just copied, is there a better way?

[00:03:40] We're gonna see, thank goodness, there is a better way in JavaScript. But this at least is a very intuitive, straightforward in some essence way. So, what is the better way?
>> multiple: Classes.
>> Student: Inheritance?
>> Will Sentance: Inheritance, everyone's shouting out words from the land of OP. Probably one of those words are gonna be correct, maybe.

[00:04:02] One of those words are gonna be correct, but how are they working. What we gonna do today is under the hood how they're working. I wanna stress to all of you and online, when I sit down with other senior engineers and say what questions do you ask senior developers in interview?

[00:04:19] One of the classic questions and there's a great core answer saying out, how can I spot a senior developer. I don't think it's necessarily a great way to spot a senior JavaScript developer but the answer, the top voted answers is ask them to rebuild how the new keywords and how classes which is one of the words shouted out are actually working.

[00:04:40] We're gonna to see under the hood how those are actually working. It is a classic senior developer for JavaScript interview question. We're gonna go through it, we're gonna build up the different ways of achieving this fundamental goal of calling our functionality immediately on our data. But not being incredibly inefficient with space like we have been here.

[00:05:05] That's our tension, we're gonna resolve it today, all right. So at this point, we're gonna get into pairs, after the pairing we're gonna see how this works. What is our better way of achieving this, but it lies on the other side of the pairing. For now folk, I think stay in the same page we're in, we don't need to go through these go to csbin.io/oop we'll get started on pairing on oop and we'll start to see afterwards, how we can do it better.

[00:05:36] Everybody, to your pairs.