Class & OOP Introduction

[00:00:00]
>> Will Sentance: We now reach our final section classes and prototypes object oriented programming, but particularly focusing on under the hood, what are some of these features that we see day to day in JavaScript. Like this prototype chain we hear about like this prototype property, we see on our Functions, like this new key word we see, like this class key word we see.

[00:00:22]
What are of these actually mean? We're not even per se so much focused here on building out the AOP paradigm as using that as a lens from which we understand the implementation of it in JavaScript, meaning understand prototype chain. It's a really elegant and beautiful thing. I'm using elegant again not know what it means.

[00:00:42]
It's a really, it's a thing, there we go. All right, there we go. So an enormously popular paradigm for structuring our complex code. Object oriented programming for years and years and years has been the way that we handle having 100,000 lines of code in one file. Not really one file, one application, having some structure so it's not just do this, then this, then this, then this and this here, but some sort of organizing structure.

[00:01:06]
in JavaScript, it depends on the prototype chain. This is the behind the scenes feature that enables us to achieve some semblance of object oriented pattern in JavaScript. But it's also as I'm saying a compelling tool in its own right is pretty nice. We're gonna understand the difference between proto and prototype.

[00:01:23]
We're going to see the new class, the new in class keywords. As much honestly for us to be able to understand, for example, in interview where one of the most popular questions to ask of a mid senior developer is, what's the newkey word doing under the hood. We're going to build it out from scratch to fully understand it as an allowed to automate some of our work, but we're also going to see the power of our functions and lexical scoping within them.

[00:01:50]
We're going to see how this keyword works. We're going to also learn about that big Headline object, the object.prototype, where we get all our shared functions and all objects get. All to come, we're gonna start it off with reminding ourselves what even is the core of development and running code.

[00:02:12]
Two things we do remember, save data and run code. In a typical application that might be, for example, the quiz games, saving the scores and the user names of two users, maybe 100 users, 1000 users all playing at once. Don't think that by seeing on the UI, like looking at the quiz games visuals that that's the data saved.

[00:02:33]
That's the data displayed, it saved behind the scenes in Java's memory. That's how it's there, so it's not magic, it's still behind the scenes. Those are just pixels. It's a behind the scenes of the computer. The other half run over application development or running code is to actually run code, functionality functions on that data.

[00:02:51]
For example, we've got a user want to use it to increasing user to score when they get a quiz question right. That is it. By the way, I don't know how we therefore have a hundred thousand lines of code and it's so complex, because that's it. Why is learning so hard?

[00:03:08]
In a quiz game, you know what, I need to save a lot of users. But not just even users, I've got to save and by the way, all of them have lots of different properties, information about them. Score, username, avatar, profile URL, email store, status, last status of their engagement with the application.

[00:03:31]
And that's just the start, that's just usage. People's got admins, we've got quiz questions we need to save. We've got quiz outcomes. We've got league tables and 1000 other pieces. All of these have data stored in our applications runtime in the memory and associated functionality that is code that we can use to interact with and use that data.

[00:03:58]
Or display it, render it, display it, change it alter updated, delete it whatever for all application is functionality and the associated data to run on that. So if we start with users, it might be, I don't know, increasing that score. It could be displaying these but in 100,000 lines of code, it gets really complicated really fast.

[00:04:18]
Where is the functionality when I need it? I've got my user one and I've got the lovely data of their score and their name, their username, but I want to update the score. But where's the function that allows me to rate the score? I've got 100,000 lines of code, where is that function?

[00:04:33]
Not only that, that function only applies to the users score. Don't get me trying to start, I don't know, or I suppose it was like a change username, or yeah, update users image. Don't try and use that functionality on my league tables. Don't try to use that functionality on my quiz question.

[00:04:53]
So not only I do not know where the functionality is in my hundred thousand lines of code. I don't know which bits of my data it applies to and that's what makes coding so complex. So much data, so much functionality and it only applies to certain bits. And finding the right functionality and making sure it only applies to the right bit, we need some sort of organizing structure.

[00:05:14]
I call that the bit here, easy to reason about. I want my code to be easy to figure out what's going on. But I also want my code to be easy to add features to. That is new functionality for any given data, like users got new functionality they can now, I don't know, they can now log in with Facebook.

[00:05:32]
I want to be easy to add functionality. But I don't want all of that to come at the expense of my code being reasonably performance unefficient cuz it might well do so. The object oriented paradigm, and really all paradigms of code, they're sets of guidelines, they're best practices approaches that allow us to achieve these three things.

[00:05:56]
They are kind of a bunch of ways of organizing our code that will together hopefully achieve these three goals. And that's what it's about, we're gonna achieve all three of these, by the way from solution to on was in my opinion. But because developers often come from other languages, their idea of what easy to reason about might not be a JavaScript native style of writing and organizing our code.

[00:06:24]
So solution three and four for achieving structuring our code in a manageable way, are primarily going to be about shorthands for writing the code that make it look a little bit more like other programming languages. In other words easier to reason about but really easy to reason about, only if you understand it under the hood.