Object-Oriented JavaScript

[00:00:00]
>> Will Sentance: Alright, classes, prototypes, object-oriented JavaScript, enormously popular paradigm for structuring our complex code. It was more so than before when React really centered around the OOP paradigm. Increasingly the functional style has become more typical in React, but this remains a powerful and significant paradigm in JavaScript, in JavaScript libraries, and in our own code because it mirrors a very popular form of structuring our large code bases that is used in other languages.

[00:00:33]
And I will say now, we have a bunch of new features within it that have emerged even in the last couple of years that make it even more possible to emulate in full the object-oriented paradigm of other programming languages, which I think is pretty cool actually. But it's all going to sit, unlike other languages where it's natively implemented, instead on top of actually a quite different way of thinking about objects, data and functionality, known as the prototype chain.

[00:00:58]
Behind the scenes, it's going to enable us to emulate OOP but actually is a pretty legit tool in its own right. We're going to understand the difference between the hidden prototype property and the prototype objects in order to undo a lot of the confusion that it is very easy to have, especially if you're coming from a more traditionally object-oriented language. Actually, raise your hands if you are coming from a language that does center most of its work around the object-oriented or classical class paradigm.

[00:01:32]
Right, over half the room. Exactly, which is over 500 people. Who knows how large the auditorium here is. Alright, we're going to then explore the new and class keywords to automate away a lot of the work that goes into using the prototype chain to emulate traditional object-oriented programming, object and method creation, and we're then going to encounter static and private, or static, private and public, static instance, private and public fields that are going to be available to us in the last couple of years, that I think is a really exciting way of extending this paradigm.

[00:02:14]
But it all starts, people, with the core of what it is to write and develop, write code and develop. And that is doing just two things. We even in a sense, in our execution context, see them. It's do code and save stuff. What does it say, save data. So suppose we have a quiz game and we are going to be spending our time building out a quiz game where we're going to have, keeping it simple, two users, saving their data, and then we run instructions, functions on that data.

[00:02:46]
For example, increasing a user's score. That is it. That is all we do within programming, save data and do stuff to it. Now that doing to it might be sending it to another computer over a network, it might be displaying it on the UI, it might be adding one to it, but it's all just doing stuff to that data that we've saved. So why is development so hard? Why are we all paid the big bucks for something that is just saving data and changing it, using it?

[00:03:16]
It's a conspiracy. No, in practice, it's because even in our quiz game, I gotta save lots of users, but also I gotta save admins, I've gotta save quiz questions, I've gotta save the outcome of the quiz, I've gotta save league table, I might even want to save, I don't know, a game board that I'm going to display. I may even want to save a part of the view that I want to display. And all the associated data and functionality that comes with each of those things in hundreds of thousands of lines of code.

[00:03:47]
And the problem with that is if all I'm doing is saving data and saving functionality to use on that data, for example, to increase the user's score, in 100,000 lines of code. Where's the functionality when I need it to change that user's data? It could be anywhere in the 100,000 lines of code. How do I make sure the functionality is only used on the right data? What data structure do I have available to me in JavaScript that allows me to store both data and functionality in one neat package?

[00:04:22]
What data structure do I have, Austin? It's an object. Excellent from Austin. I will say, what did we see earlier, not to throw us off course, but what do we see earlier? What's another way we can store functionality with associated persistent data? Closure, functions with associated persistent data, is an alternative way of doing much of the same idea. Exactly, and functional programming rests on that idea, because the idea still is, I've gotta keep my functionality and my data close together.

[00:04:50]
But we are now approaching it from the other way, and these are two almost rival competing paradigms, the functional and the object-oriented paradigm. We are now focusing on it from the object-oriented paradigm, put our data and functionality bundled up within an object. Amazing. Yeah, I guess that is, I want my code to be easy to reason about. Oh, why do I say this? Yeah, an object. Yeah, but I want my code to be easy to reason about, work out how across 100,000 lines, 100,000 lines of code, I can find what I need.

[00:05:23]
But I do have two other crucial constraints. Yes, I want to keep my code easy to reason about. Where is my increment function to increase the score of a user, increase the user's score, and the user's data? I want to keep them close together, but I have two other major constraints. I cannot have that easy to reason about because my data and functionality are bundled together, but also not make it efficient and performant.

[00:05:47]
I can also not have that make it difficult to add new features or functionality. I don't know why I made those flip. Let's instead say I needed to be easy to reason about, but also easy to add new features. I need it also efficient and performant, and it's going to turn out that these things might be a bit in tension. Easy to reason about, for example, make sure my data and functionality are right next to each other, not searching through 100,000 lines of code, might be in tension with performance.

[00:06:14]
Might be in performance for performance, meaning not taking up too much memory space, for example, not filling up the memory unnecessarily. Easy to add features or functionality to, let's say, enable the user to lose a point. I need to make sure that doesn't also harm my easy to reason about. These things are going to be in tension. The object-oriented paradigm aims to let us achieve all three of these goals at once.

[00:06:40]
OK, so using objects. If I'm storing each user in my app with their respective data, let's keep it really simple, we're just going to have user one, user two. We've also got very nice three-letter names here, Ari and J. Ari's score is 3, J's score is 5. And the functionality I need to have for each user, again, keep it really simple. They're going to have just the ability to increase their score. In fact, there'll be tons of these functions.

[00:07:03]
Increase, decrease, log in the user, log out the user, display the user in the view so the user can see their score. How can I store my data and functionality together in one place? Austin again. Objects. Objects, excellent, Austin, exactly.