JavaScript: The Hard Parts JavaScript: The Hard Parts

Introducing Object-Oriented JavaScript

Check out a free preview of the full JavaScript: The Hard Parts course:
The "Introducing Object-Oriented JavaScript" 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:

After reviewing material so far covered in the course, Will introduces Object-Oriented Programming (OOP) in JavaScript.

Get Unlimited Access Now

Transcript from the "Introducing Object-Oriented JavaScript" Lesson

[00:00:00]
>> Will Sentance: At this point, we have seen our asynchronous land. A lot of this is hidden from us. So we don't often know exactly how some of these pieces are working but we just need to know that when we use any of these built-in features, which we access with things like $.get, that we access with things like set time out.

[00:00:18] They're all setting up things in the web browser API land, with the associated referenced callback function that got passed in. That is not like our regular callbacks. They get executed immediately here inside their high order function being called, no. Instead, they get referenced in the API space then when they complete whatever that looks like, the timer, the timing's completed.

[00:00:47] If it's an HTTP request, an XML HTTP request, API use, we get complete when the request returns with data and then that associated function added to the queue, queued up. And then, only when our event loop is checked successfully, the core stack is empty, and global has no more code to run, do we then pass a call to the display function, to our call stack.

[00:01:17] And then, we call it, with the data available to us, from the request return response. All right, so asynchronous callbacks. Web browser APIs, by the way, known in node as background threads in C++, the callback queue and our event loop allow us to defer our actions to display data functionality until our work, maybe an API request, maybe a timer, is completed.

[00:01:48] And then continue running our code line-by-line. [INAUDIBLE] log me fast, instantly. Asynchronous JavaScript is the backbone of the modern web, letting us build fast, dynamic, they're interactive with things beyond theirselves, but non- blocking applications. We did not block the main thread while we waited for that data to come back and then call the function display to run with that data.

[00:02:14] Instead, we just said, continue on, and when finally that API request completes, then bring the associated function back into JavaScript via the callback cue event loop and then call stack, call it with the data available as the argument. That's it, this is our asynchronous JavaScript, okay? And now we move on.

[00:02:37] We're almost there. Part 1, principles, done. Part 2, higher order functions, done. Part 3, closures, done. Part 4, asynchronous JavaScript, [SOUND] done. Done one final part, object-oriented JavaScript. Approaches to OOP, object-oriented programming, in JavaScript. OOP, an enormously popular paradigm for structuring our complex code. As we write more and more complex code at scale we need to a way of structuring it.

[00:03:15] We've seen one, which was our functional paradigm. But we said that there'd be an even more popular alternative that's been the main go-to way of thinking about structuring and writing our large scale code bases over the last 25 years. It is the object-oriented paradigm. Why do we have a paradigm for structuring our code?

[00:03:39] Let's remind us, it allows us to easily add features of functionality ideally. When you've written some stuff, we don't have to rewrite the whole thing again to make it do new stuff. Performant, it doesn't unnecessarily use up a ton of memory, for example. Sometimes these may actually be intentional with each other.

[00:03:58] And part of the principles behind their best paradigms is to somehow reconcile these. For example, we want to make writing code easy, adding features and functionality easy. That might have challenges in terms of memory efficiency. We want it to be easy for us and other developers to reason about, to think about exactly how our code is working.

[00:04:22] These are all things we want as we write large scale code. And the OOP paradigm, through a number of features of it, makes these things possible for us. So I'll say this, for OOP, in JavaScript, whereas for our closures, our higher order function, our a-sync, we can see them purposefully being used for making a memo-wise function.

[00:04:46] Remember that one which remembers the last time it was run? We can see them being useful to use pretty immediately. The module person, yeah, we have to imagine why we wouldn't want to pollute the global name space. Remember this from yesterday, why we have a module pattern. OOP is harder to see instantly why we would want it.

[00:05:03] So we're gonna focus on one particular thing, which is that it's easy for us to add features, easy for other developers to reason about if we achieve this goal. When we're running code, we're mainly doing functionality to some data. That's most of the time what we're doing. We're applying some functionality to some data, some information.

[00:05:27] That's mostly what we're doing. Well that's the case. It would be incredibly helpful if all relevant possible functionality that could ever be applied to a particular piece of data would be immediately available to be run on that data. Not in some separate other part of the application, not in some other random location, but there on the data available.

[00:05:53] What I mean by that is suppose we want to imagine we're building a mega scale application, a quiz game with lots of users all playing together at the same time. Here's some of our users. Name, Will, score, 3. Name, Tim, score, 6. Okay, fine, let's imagine there's actually 100, 200, 5,000 users, each with a name and a score.

[00:06:17] My friend, Tim, went to school in the city. Shoutout to Tim, there you go. And, look at this, so functionality, the ability to increase the score of these users. And I want my Will user with that data to be able to have the functionality and increase my score right there available on that data.

[00:06:40] And I want to have my Tim user have that functionality available sort of wrapped up somehow, bundled up, right there on my name, Tim, score, 6, user. And there may not just be one piece of functionality, there may be hundreds. But, what would be the best way to store this data and functionality in one sort of easily bundled altogether way?

[00:07:03] Griffin, what would be a good way of doing it?
>> Griffin: The objects?
>> Will Sentance: In an object. That's a very nice way, storing our functions as methods and our data as properties on objects. That's exactly right. Note we would in reality have a lot of different relevant functionality, not just increase score but could be ability to decrease score,To delete user, to log the user in, log it out, add an avatar, get user score, display user.

[00:07:29] All that functionality could be applied to this user. So we want to bundle up, in an object, our data associated with the user and our functionality. So as we build our game, we're gonna have users with data and relevant functionality that could be applied to those users. It turns out that a really great way of putting these all in one place is to use an object.

[00:07:57] Cuz what does that let us do? It let's us do this all powerful line here. And throughout the rest our OOP session, we're gonna be measuring ourselves against can I do this line here? As a developer writing functionality, if I got my functions that could be applied to a user all over the place, I've got all sorts of question marks.

[00:08:19] Is that function available to run on this user at this moment? What about, if I got my functionality, all the functionality that could ever be applied to that user, available on the end of a dot, in other words, wrapped up available on that user1 object. This makes my life writing code at scale far, far, far easier.

[00:08:43] So throughout our session we are gonna be testing ourselves. Have we achieved this simplifying, is simplifying gotten? Yeah, this simplifying goal of making sure the functionality that we could apply to our user data, in this case user 1, Will 3, is available right there on the user. The user 1 on increment, we could imagine user 2.increment.

[00:09:10] Is that functionality available on the user? This idea of binding together our data and functions that can manipulate that data is known as encapsulation. Which is one of the core features of the OOP paradigm.