The Hard Parts of Object Oriented JavaScript

Intro to Subclassing and Inheritance

Will Sentance

Will Sentance

The Hard Parts of Object Oriented JavaScript

Check out a free preview of the full The Hard Parts of Object Oriented JavaScript course

The "Intro to Subclassing and Inheritance" Lesson is part of the full, The Hard Parts of Object Oriented JavaScript course featured in this preview video. Here's what you'd learn in this lesson:

Will introduces inheritance as a way to create subclasses within JavaScript and explains why inheritance is a misleading term.


Transcript from the "Intro to Subclassing and Inheritance" Lesson

>> Will Sentance: We saw that they get bonus stuff, bonus functionality available to them, that are not properties directly on them. But instead, we have the ability to go and look up when we refer to something like hasOwnProperty on obj, to go and look up at this little collection of functions here in this built-in function object combo going by the name of object.

>> Will Sentance: That has a probably identical prototype in its object version that is an object full of functions, that all objects by default link to. This is nice. This is JavaScript, using its own technology, to let itself give its objects, and then its functions, also, access to bonus functionality.

What this means is that we can do the same thing for our objects that we produce in our kind of object-oriented application design. We can say, okay, this object user one will access to this collection of functions, but that collection of functions itself could have access to another collection of functions that we can keep going and checking up.

Meaning, we can kind of order the distribution of our functions among our objects in a really nicely structured way. It's known as subclassing. Hopefully, that's the next slide. It's not there, there it is, subclassing. It's known as subclassing. A core aspect folk of object-oriented paradigm, is the notion they call it inheritance, passing knowledge or work that's been previously written down.

So let's look at these, you've got user, I meant to user create, well whatever. User, then it's gonna have a name and a score, and access, not directly on the user one object, but access to increased score functionality. We saw that, it's in our kinda bundle of functions.

We have increment and login. But a lot of time in application design, we always have users. User1, user2, user3, were all identical in what properties and functionality apply to them. Typically, we have kind of sub-users. These sub-users might be a moderator type of user. It's very similar to a user, it has a name, it has a score, but it has the ability to share a public message.

This is a moderator in our quiz game, or a paid user. Man, there's my first error in the slides. The paid user has yes name, yes score, but also has a property on any paid user. For example paidUser1, they're just like a user, they have name and score.

But they also have an account balance, cuz they're a paid user. So ignore the bonus score thing there, account balance. They therefore also have functionality associated with them, increase that balance. But they also still have a score properties, they also still wanna have the increase score functionality. So how can we create paid users like paidUser1, but use the property development that we did earlier.

The property creation process that we did earlier, and the functionality that we created earlier, not have to redo it all over again. But use that in creating our paid user. And then add some bonus stuff. This is known as inheritance, not redoing all the work to create a paid user.

But using a lot of the work that was done to create a regular user to create a paid user, and then adding bonus stuff. Okay, let's notice subclassing. Subclassing is the creating something which like a subversion, a kind of slightly more specific version of a user. And that notion of grabbing the previously done work, to make it available to our paid user is known as inheritance.

I do not like the term inheritance used in JavaScript particularly, cuz it makes you feel you're actually taking that stuff from up here, and sort of sticking it on this object down here, you're not. It's gonna be just like we did here, that our function mode probably too had access to these functions.

Had access to this function one level up. Did they inherit these functions? Seems a weird term to describe at run time the ability of multiply by 2 to go and look up to find stuff. Is that really inheriting? Feels more like you have the right to go look up.

Find the term inheritance, an odd term, if folk understand why I'm saying that, but it is in the sense of the languages the notion of getting access to stuff. But when you inherit a property genetically, you literally get it on you. Well, that's not what's happening here. We're just gonna get the right to go and look up to get stuff.

So I don't like the term inheritance but it is the standard term.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now