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

The "Object Oriented Paradigm" 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 gives an overview of what will be taught and then answers why a paradigm, or way of organizing code, exists at all.


Transcript from the "Object Oriented Paradigm" Lesson

>> Will Sentance: And now we come to object-oriented JavaScript. The new hard parts of OOP. We are used to seeing in hard parts, a whole bunch of functional programming features. This has been the burgeoning paradigm for the last few years, but nevertheless still remains a core way of thinking about code, object-oriented programming.

It makes up still a major part of the react design pattern. And in today's session, we are gonna dive deep in completeness into how object or into programming works. We're gonna lay out the number of ways by which we can produce objects with their associated functionality all bundled up nicely.

We're gonna dive deep on call and apply. We're gonna see how the prototype chain plays out. And the hardest part of all, which is gonna take a bunch of time, maybe even a few minutes, a bunch of time, subclassing. And we're gonna do that both in a, what's called factory function style.

We're gonna do it in a new keyword style and we're gonna do it with the new ES 2015 classical, or class style. But it all begins with, us asking ourselves, why do we have a paradigm, a means of organizing code at all? It comes down to this. When you're writing out thousands of lines of code, one after another, you do not want to just have do this, then procedurally do this next command, then do this next command, then do this next command.

You wanna have some way of organizing it, such that, well what do we do when we run code? We're essentially saving data, think a quiz game, as you're gonna build out a quiz game today. Think of a quiz game, we're saving data for the quiz, say user score, a user's name, multiple users each with scores and names.

Multiple quiz questions and then, we're applying functionality to that data. We're saying, okay, here's, I don't know, user one who's playing, user two who's playing. They both need to have the ability for their score to be increased. But we've also got some quiz question data. The description of the quiz question, or the actual question itself.

That quiz question data, that is, the words of the quiz question, we don't wanna be applying functionality saying increase score to the quiz question. But really all we're doing when we run code or write code is saving data. Quiz questions, scores of players, names of players, and then applying functionality to use that data, or change that data, or render, that is display that data.

So that's all we're doing, wouldn't it be nice if we could combine up the appropriate data. Let's say, it's a user's data named Phil, score four in our quiz game, with all of the functionality that we could ever want to have applied to that data. So we don't have to go and hunt, go run off to try and find what functionality's applicable to this data.

Don't worry, it's gonna be bundled together somehow, kind of packaged up. And for our quiz question, we don't have to go and hunt after our display quiz question functionality. Don't panic, it's all bundled up there with the quiz question. It makes our life incredibly easy. So what is a paradigm?

A paradigm means any approach to organizing our code that, well, let's have a look. That hopefully makes it easy to add features and functionality. That hopefully, if I want my users in my app to now not only be able to increase their score, but decrease their score. Hopefully, it's easy for me to have all my users the ability to have their score decreased.

But also, easy for us and other developers to reason about. Not do this and do this and do this, and it's 40,000 lines of code one after another, but instead. This is a good organizing method, or organizing approach. We have our data that represents, in this app, users.

And then attached to it, the functionality that applies to those users. We have our data that represents a quiz question. And attached to it, the functionality that says, display that quiz question. No hunting for it, it's right there. And hopefully, by the way, this organizing approach does not come at the cost of performance.

Doesn't say, well, it's made our lives easier, but man, now it's really slow. Or now it's wasting a ton of memory. Yes, it's more organized, but there's a ton of memory wasted. That's what we hope. A paradigm is an organizing structure for our code that hopefully maintains these things.

We need to organize our code as it gets more complex so it's not just an endless series of commands. So the question is, how might we, I turn to Michael. How might we Michael, bundle up our data? Say, you use a score name with the appropriate functionality that applies to that data.

How might we bundle those up would you say?
>> Speaker 2: I usually would bind them up with different separate classes and-
>> Will Sentance: True, but in a very, very simple manner, we might just bind them in the-
>> Speaker 2: Object.
>> Will Sentance: In an object, beautiful. Just put them in an object.

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