This course has been updated! We now recommend you take the Deep JavaScript Foundations, v3 course.

Check out a free preview of the full Deep JavaScript Foundations course:
The "Prototypes Introduction" Lesson is part of the full, Deep JavaScript Foundations course featured in this preview video. Here's what you'd learn in this lesson:

In JavaScript, every object is built by a constructor function and does not mean classes are being instantiated. When a constructor function is called, a new object is created with a link to the object's prototype.

Get Unlimited Access Now

Transcript from the "Prototypes Introduction" Lesson

>> Kyle Simpson: Moving on to our next topic in this unit, Prototypes. This one is a biggie because this one is from where all other object oriented programming patterns in JavaScript is done and I want to make sure we fully understand how Prototypes work. So the first observation we need to make is that objects are built by constructor calls, not by constructors, cause there aren't such a thing, but objects are built by constructor calls.

[00:00:29] What was a constructor call?
>> Speaker 2: A function called with the new keyword.
>> Kyle Simpson: A function with the new keyword in front of it. That's essentially where objects are gonna come from, okay?
>> Kyle Simpson: Now, it's often said that that constructor call is gonna make that object based upon a constructor's own prototype, but this phrase based on is problematic.

[00:00:54] So temporarily, just for a moment, I'm going to take off my hat as a JavaScript developer and talk more as a computer scientist in the context of class design, specifically classes that we think about in C++ and Java. Referring back to my own experiences in computer science, the way I was taught about things Is the first metaphor they use to describe the instantiation of a class, is the blueprint metaphor.

[00:01:21] The blueprint metaphor being, there's a blueprint for a building, but that building doesn't exist until the builder takes that blueprint and physically makes the building out of it, right? In a sense, that process of taking a blueprint and making a building out of it. I would argue the essence of that is a copy operation.

[00:01:44] Specifically, what I mean by that is the characteristics listed in the blueprint are copied to the physical building. It is not that there's some kind of live link relationship between the two. That relationship exists, only in the instant in which we copy the characteristic from blue print to physical building.

[00:02:03] And then it ceases to have that relationship. If I go to the blueprint, and I erase a wall It doesn't take the wall out of the real building does it? They're not linked. If I go to the building and I knock out a window, it doesn't erase the window from the blueprint does it?

[00:02:22] Because they're not live linked. There was a copy. There is a separation in their relationship. That relationship was simply a copy relationship. Furthermore when we talk about inheritance in class-oriented coding, the genetic metaphor is usually used. Genetics like when you biologically create an offspring. So I have a son and when he was created, biologically he got a copy of my DNA.

[00:02:47] It was clearly a copy of my DNA not my own DNA but a copy of it. Now, we are two separate individuals. If he breaks his leg, my leg does not get broken. If I lose my hair, hopefully he doesn't lose his hair.
>> Kyle Simpson: Because our relationship biologically was a copy relationship.

[00:03:09] Every follow that? The same is true in class oriented coding. When we instantiate something from a class we conceptually think about that as being a one time event. We don't think about there as being a link between the instance and where it came from. If a utility If a language allowed you to instantiate an object, and then modify the class definition after you had instantiated the object, would you expect for that object instance to be able to have the new behavior?

>> Kyle Simpson: If I broke my leg, would you expect for my son's leg to get broken? There's a term for this, it would be retroactive inheritance. There's an actual term for it. But most people don't choose to imply retroactive inheritance as their design pattern for their code. So if you had a system that allowed retroactive inheritance and you used it, there's a more likely chance that people reading that code might get a bit confused.

[00:04:17] Wait a minute. This instance already exists, and somehow you were able to magically give it behavior that it did not have at the time it was created at? That is unusual. Okay. So back to JavaScript. When we say based on that sure implies to me at least, reading that that phrase implies that there was a copy.

[00:04:41] That we made the object as a copy of the constructor's prototype.
>> Kyle Simpson: So it might surprise you when I point out that JavaScript doesn't do copying. If class systems imply copying at the conceptual and even at the physical level, and JavaScript doesn't do copying, maybe that's our first clue that JavaScript doesn't really quite work the way we expect classes to work.

[00:05:08] The more appropriate statement here is that in JavaScript a constructor, or a constructor call will make an object linked to the constructor's prototype. Not based on, not a copy of, but a link to.
>> Kyle Simpson: So there's a difference here, conceptually and physically between how we know C++ and Java to have implemented classes, and how this system that gets called classes in JavaScript actually works.