JavaScript Advanced - Prototypes, Inheritance & Objects 2026

Learning about the [[Prototype]] is extremely important, because every object you create in JavaScript will automatically get this property.

You have a lot of questions right now, like: 

• why does it have square brackets [[ ... ]]

• what does it do? 

• why is it there

• why can't we just use the __proto__ proto? 

• etc

Don't worry, I answer all of these questions, plus more, in this section.

You may be wondering why prototypes are so important, if JavaScript is obsessed with objects.

Hmmm ....

Time to talk about the 2 most important and basic rules about the [[Prototype]] property.

#1. every object you create will by default have a [[Prototype]] property

#2. the [[Prototype]] has to be an object, or null

ECMAScript have defined a few properties that by design are hidden and therefore not accessible in code. One of these properties is the [[Prototype]] property.

Although the [[Prototype]] property is essential for JavaScript's functioning, it is not intended for direct manipulation in typical programming scenarios. Instead, developers interact with prototypes through higher-level mechanisms and syntax, such as Object.setPrototypeOf(), Object.getPrototypeOf(), object literals, constructor functions, the Object.create() method, or modern JavaScript features like classes and the extends keyword.

ECMAScript defines various internal properties, of which [[Prototype]] is one. But why is this? 

Developers love to confuse everyone.

As you have just seen in the previous lecture, I called the [[Prototype]] property a hidden property.

But according to the ECMAScript specification, they call it an "internal slot".

So in this lecture I want to explain what an internal slot it and why they were introduced into the Spec.

Getting and setting prototypes is as easy as 1, 2, 3.

When you write JavaScript, you'll be creating objects from different data types, like Strings, Arrays, functions, numbers and more!

But did you know that no matter what data type you're working with in JavaScript, almost all of them inherit from the Object interface (except null).

In this lecture I'll expand on this.

Things can get a little complicated with primitive data types. Although you can't see, add or remove properties from a primitive, it still inherits from the Object.prototype.

WHAAAAT?

Let me explain.

Null is treated in a very unique way in JS. ECMAScript correctly refers to null as a primitive value, but then when you ask the JavaScript engine what type null is, it returns an object.

What?
So then, is null an object or a primitive? 

I mentioned in the previous lecture that almost all data types in JavaScript inherit from the Object.prototype. The reason I said this is that primitives don't directly inherit from Object.

Primitive data types reference the value directly in JavaScript's memory allocation. What this means is that they don't have any properties or methods attached to them, and you can't add any properties and methods to them either.

But you'll notice that even when working with primitive data types, sometimes you can access properties and methods you did not create, like toUppderCase() for example. This is possible because the JavaScript engine will create wrapper objects behind the scenes, allowing your primitive variable to access its prototype properties, and after that's done the JS engine will delete the wrapper object.

In this video, I'll explain this in simple terms.

This can be rather confusing, but I hope by now you understand that: 

1. In JavaScript, there are 2 data types. Primitives and objects.

2. Primitives are the simplest data type, because they are allocated in memory and reference the value itself.

3. You can still use certain methods and properties on primitives that come directly from their relevant prototype. This is possible because the JS engine creates temporary wrapper objects.

Primitive objects are limited. But there is a way to create a "primitive" that will give you the power of fully-fledged object. To do that, you need to create an object using a constructor function.

We've learnt a little about primitives so far, that although we can't personally add properties and methods to it, it still nevertheless inherits from the Object.prototype.

This lecture is a summary.

Creating custom [[Prototype]]s is fundamental to writing clean and streamlined code. This is an important rule.

The old way to set an object's prototype was to use the __proto__ property.

A newer way is to use the setPrototypeOf() method.

But there are also other ways to set a prototype, like using the Object.create() method, or even better, using factory functions. 

In this lecture I'll show you both in action.

In the previous lecture I set the object prototype using both __proto__ and the setPrototypeOf() method. Don't worry for now about these methods. I'll be getting into more detail later in the course.

There are different ways to set an Object's prototype. I have already shown you how to use __proto__ and Object.setPrototypeOf().

But please bear in mind that these are not the most optimal ways to set an object's prototype when you are creating a custom object.

You can also set an object's prototype using Object.create() and by using factory functions.

The default scenario is that the [[Prototype]] of an object literal will point to its constructor function's prototype value. Huh? Don't worry, let me explain what I mean in this lecture.

It can be confusing to deal with terms like "prototypal inheritance" and "inherited properties". In this lecture I'll recap what we've done so far in the course.

Up until this point, I've spoken about properties being subject to the prototype chain, but I want to prove to you that this also applies to methods and functions.

The prototype chain is a fundamental concept in JavaScript's inheritance model. It describes the mechanism by which objects inherit properties and methods from their prototype objects.

The power of understanding prototypes is creating objects with their own prototype chain.

When you access a property or method on an object, JavaScript first checks if the object itself has that property. If not, it looks up the prototype chain to find the property on the next prototype object. This process continues until the property is found or until the end of the prototype chain is reached (i.e., when the root prototype is reached).

You know me. Actions speak louder ? than a 1000 words, so let's see an example.

All good things come to an end, and this is no exception to the prototype chain. The prototype chain has to end at some point, and it does so with the value of NULL.

We've come a long way, so let me recap why the [[Prototype]] property is so important to master.

A quick word on leaving reviews

Although we have flexibility as developers, we have to abide by rules. There are 3 limitations with regards to what we can set the prototype too.

Just because a particular property or method is included in the prototype chain, this does not mean that it can't be overridden or over-shadowed. In fact, if you have 2 property names that are identical, the first time the JS parser finds that property, it will use that one and not travel further up the prototype chain.

In JavaScript, shadowing prototypes refers to the process of overriding a property or method of a prototype object with a property or method of the same name in an instance object. When a property or method is shadowed, it means that the instance object has its own definition that takes precedence over the one defined in its prototype.

Quick summary of what shadowing means.

In the previous lecture I wrote "this", which is a special JavaScript keyword. The question you probably have, is whether setting the prototype will affect the value of this.

A key part to developing a web app is the ability to loop through objects. Before I discuss how prototypes affect this, I want to introduce you to the FOR...IN loop which is a JavaScript looping function.

If something is "enumerable", it means that it can be counted.

In the context of programming, it means that the properties/methods of an object can be looped through by the JavaScript engine.

Properties defined via an object literal are enumerable by default. I'll show you in this lecture how you can take more control and decide to set a property as non-enumerable.

You may also be thinking "why does it matter?" The short answer is that it matters because enumerable properties will be returned by a JS loop all the way up the prototype chain.

In JavaScript, there are several methods available for iterating over arrays and other iterable objects. These methods provide a convenient and expressive way to perform operations on each element of a collection.

We've seen the for...in loop, but there are limitations to this. Firstly, its a little clumsy and secondly, it will also loop through the entire prototype chain. Often, you don't want this to happen.

Today, since ES6, we've been given a lot of modern ways to loop through pure objects.

The JavaScript engine is highly optimized for setting the prototype property at the same time the object is being created. So once done, don't mess around with it again.

Modifying built-in objects in JavaScript is generally not recommended because it can lead to unexpected behavior and conflicts with future versions of ECMAScript. It can also cause issues with other libraries that rely on the original implementation of the object.

Instead of modifying built-in objects, you can create your own objects that inherit from the built-in objects and add your own methods to them. This way you can extend the functionality of the built-in objects without modifying them directly.

You'll often see developers say that using Object.setPrototypeOf() is not good.

BUT ... there are always exceptions to the rule.

Sometimes, like when you are dealing with functions, you may have to change its prototype after creation. In fact, you have to do this if you want to create longer prototypal chains of your own. We'll get into more detail of this later in the course. I just wanted to give you the heads up.

A quick recap on the previous lecture

We've learnt a lot in this section. Well done!

You can create objects in JavaScript numerous ways. The most simple is using the object literal approach, by using the curly brackets {}.

However, as I'll show you in this section, more experienced developers use functions to create objects. By doing this, you have more control over the object and you can (eventually) use these techniques to define which objects should inherit what prototypes. Super exciting.

In JavaScript, an object literal is a comma-separated list of name-value pairs wrapped in curly braces {}. However, there are some cases where object literals may not be the best way to create an object. For example, if you need to create multiple instances of an object with similar properties and methods, it may be better to use instantiation patterns instead of an object literal.

Instantiation patterns are different ways to create objects in JavaScript. Each pattern has its own strengths and weaknesses. The different patterns can help developers write less code and make their code easier to read and understand.

For example, if you want to create multiple instances of an object, you can use an instantiation pattern to create a template for the object. This template can then be used to create multiple instances of the object without having to write the same code over and over again.

An instantiation pattern is a way to create an object using functions. There are several instantiation patterns such as Functional, Functional-shared, Prototypal, Pseudoclassical and Classes. We will be learning about all of them in this section.

Excited? 

Me too.

There is not one way to create an object in JavaScript.

That is why this section is dedicated to teaching you about the different, and more advanced, ways to create objects in JavaScript.

Functional instantiation is a way to create an object using functions. It is one of the five instantiation patterns in JavaScript. This pattern creates an object and assigns both its properties and methods in the same function call.

Although Functional Instantiation is an improvement from using object literals, it is not perfect. Specifically, it still suffers from memory duplication and this is caused by no shared lineage.

My final two-cents worth on functional instantiation.

Functional shared instantiation is yet another way of creating objects in JavaScript. It is a way of creating objects in JavaScript that allows you to create multiple instances of the same object that have the same pointer in memory to shared methods. However, it's not perfect, as I will show you.

It's time to show you how functional shared instantiation works.

My final two-cents worth on functional shared instantiation.

Yep, you guessed it, prototypal instantiation is yet another way of creating objects in JavaScript.

Prototypal instantiation uses the full power of JavaScript's prototype chain to create objects. Under the hood, methods are attached to the object’s prototype using the Object.create() method.

Confused? 

Let me explain.

In prototypal instantiation, methods are attached to the object’s prototype using the Object.create() method.

It will come as no surprise then, that in order to understand prototypal instantiation, you need to first understand Object.create().

The Object.create() method is used to create a new object with the specified prototype object and properties. It creates a new object using an existing object as the prototype of the newly created object.

In this lecture you will see how to amend our previous code (when we looked at functional shared instantiation) to utilize the power of prototypes in JavaScript.

Prototypal instantiation is a way of creating objects in JavaScript. It utilizes the prototype chain to create objects.

My final two-cents worth on prototypal instantiation.

Pseudoclassical Instantiation is similar to prototypal instantiation in that it uses the prototype chain to create objects. However, it is an advanced method of object creation that requires less code writing than other instantiation styles. Pseudoclassical instantiation attempts to overcome the amount of typing required to create an object using prototypal instantiation, by using the .... NEW keyword in JavaScript.

It's now time to see the pseudoclassical approach in action. You'll see how similar it is to using the prototypal approach.

My final two-cents worth on pseudoclassical instantiation.

Adding all properties and methods to an object’s prototype can lead to performance issues. This is because when you add a property or method to an object’s prototype, it becomes available to all instances of that object. If you have many instances of the object, this can lead to a lot of memory being used.

Instead, it is recommended that you only add properties and methods to an object’s prototype that are shared by all instances of the object.

We've seen that you can't just add all properties/methods to the prototype. This is because in many cases you'll want unique properties attached to your objects and you don't want them shared.

But the other side of the coin is that adding all properties/methods to the constructor function means that those properties/methods will be added to the objects directly. This also poses problems, especially if you want certain properties and methods shared across all instances.

You may be wondering why I am defining my constructor function as a "Function Declaration". Why am I not using the newer and "improved" arrow syntax? 

Well, the short answer is that the arrow syntax cannot be used as a constructor function. The reason why is that the arrow function treats the this keyword very differently. And as you know, this is very important when it comes to using the new keyword.

You may be tempted to use the newer arrow syntax when defining constructor functions, but this is not a good idea because, quite simply, it won't work. Arrow functions cannot be used as constructors and calling them with new throws a TypeError.

The reason it won't work is because the arrow syntax has no binding of this. In regular functions, the this keyword represented the object that called the function, which could be the window, the document, a button or whatever. With arrow functions, the this keyword always represents the object that defined the arrow function

ES6 introduced the "class" keyword. It really does not do anything new, but it wraps everything in a nice to follow, easy syntax.

My final two-cents worth on class instantiation.

I've attached the code of all 5 instantiation patterns to this lecture.

Instantiation patterns are perhaps the most difficult concepts to grasp in this course. So, if you're still with me at this point, well done.

Let me be clear - the [[Prototype]] and __proto__ properties are similar, but not the same.

Many developers still use the __proto__ property but as I'll show you, this is mostly deprecated and there are more modern techniques you should use to get and set an objects prototype.

In this lecture you'll learn: 

• that although JS in the olden days had prototypal inheritance, it was a nightmare to work with

• because JS limited how you could interact with the [[Prototype]], Firefox/Mozilla created the __proto__ property in 2006

• __proto__ is pronounced "dunder proto"

• ECMAScript version 5.1, in 2011 introduced Object.create() and Object.getPrototypeOf(), which for the first time allowed developers to create objects and at instantiation define its prototype.

• Later, ES6 (or ES 2015) introduced Object.setPrototypeOf() method, which allows you to set an object's [[Prototype]] property, at any time

This means that today, there is really no need to have to rely on __proto__, as you have all the tools under your belt to mess around with prototypes.

Where did __proto__ come from?

Proto is a getter and setter.

According to Dr. Axel Rauschmayer, a JavaScript expert and author of “Exploring ES6”, double underscore should be pronounced “dunder”.

So proto is pronounced "dunder proto".

In this lecture I'll explain where the term "dunder" came from.

Even though __proto__ is a way to access and set the internal [[Prototype]] property, it is not internal.

WHAAAAT!

That's right. This means you can access and use __proto__ directly from code. 

You can view the __proto__ as a tennis racket, and the [[Prototype]] as the tennis ball.

__proto__ has had a weird history. Firstly, ECMAScript wanted nothing to do with it. That's why they did not include it in their spec until 2015! Then when they did include it, they included it in Annex B as a deprecated feature. But the story is not over yet. In 2022 they decided to move part of it out of Annex B, and have now officially said you can use __proto__ inside of an object literal.

In the old days, we only had __proto__ if we ever wanted to change an object's prototype after we created the object. Developers could use use __proto__ to either get or set an object prototype. It was pretty useful.

But in 2015 ECMAScript have given us all the methods we need to do the same thing as __proto__.

In this lecture I want to show you the 3 ways you can set an object's prototype, in compliance with ECMAScript, and the 1 way you can get an object's prototype.

Although we have the standard way of setting a prototype via setPrototypeOf() method, you should not use it.

Sometimes, it's good to take a step back so you can see the painting on the wall.

__proto__ has been around since 2006, which means that it has been well tried and tested. However, ECMAScript are stubborn, and they have not included it in their spec fully. What ECMAScript have done is partially allowed the use of __proto__ inside of an object literal, but for generally setting and getting a prototype, there are other methods we are asked to use.

We are stuck between a hard place and a rock.

On the one hand, we know ECMAScript has had difficult with __proto__.

On the other hand, we know ECMAScript has changed its mind with regards to __proto__ and today part of it is outside of Annex B.

The issue we face is that ECMAScript has not made it clear why they have such a problem with __proto__. This is why it's difficult to figure out and piece all of the puzzle pieces together.

let me give you my top reasons why I think ECMAScript has had such big issues with __proto__.

One of the problems with __proto__ is that you can easily think you are only effecting a specific object's instance, when in reality you are affecting the true prototype and thus all object references to it.

The next problem that you'll hear about is that __proto__ is a special keyword and therefore if you want to create basic object's you won't be able to add the __proto__ as a key to your object.

We have seen that one problem with __proto__ is that its a special keyword in JS.

More than this, we can't set it to a string, because as you know, [[Prototype]] can only be an object or null.

This is not the end of the world, though. What we can do is implement a little trick to truly create an empty object. This will allow us to do whatever we want with __proto__, including assigning it to a string.

Although you can use __proto__ as a getter and setter, there are better ways to do this. I therefore don't recommend you use dunder proto.

MDN is a place that developers go to often to read technical information on certain topics.

You've done it! Well done for getting through this section. I know its been hard and challenging at times. And for good reason. Information about __proto__ is hard to come by on the web, and even the latest chat bots don't know the answers.

Pat yourself on the back because now you know what 99% of others don't.

See you in the next section.

You've now learnt about the __proto__ or dunder property. Well done.

Almost every function has the "prototype" property even if we don’t supply it.

The default "prototype" is an object with the only property constructor that points back to the function itself.

Remember what I said in the previous lecture, that "almost" every function in JavaScript has a .prototype property? Well, this implies that some functions do not have a .prototype property. For example, we know that arrow functions and bound functions do not inherit a .prototype property.

Let me explain more in this lecture.

In this lecture I'll show you why many developers get confused when they hear the word "prototype". It can often be used quite loosely and unless you make it very clear what specifically you're talking about, it can cause a lot of confusion.

I know it can be daunting learning about JavaScript's prototypal structure.

But let me make matters worse.

Did you know what the [[Prototype]] is not the same as the .prototype property of a function? 

Heh?

In this lecture i'll explain.

The main use of the .prototype property is that it is used to set the [[Prototype]] property of newly created objects.

Although I said that the .prototype property is only applicable for constructor functions, that's not 100% entirely true.

A constructor function in JavaScript is a special type of function that is used to create new objects. When a constructor function is called with the new keyword, it creates a new object and executes the function body. The function body is where you can initialize the properties and methods of the new object.

But, there is a more technical definition of a function constructor, and that is, it has both the [[Call]] and [[Construct]] methods.

This is rather obvious, but the .prototype property is an object. This just means that it contains properties and methods, as any other object would.

When you set up an object by using the new keyword, how does the JavaScript engine who what to set that object's [[Prototype]] to? Answer: it sets it equal to the constructor function's .prototype property.

Functions in JavaScript are a different kettle of fish. By default, almost all functions have both a .prototype property and a [[Prototype]] property.

If you were paying attention, I'm sure you noticed that the .prototype property is of type function! What! By default the .prototype property should be an object, right? In this lecture I'll explain why this is the case.

Functions in JavaScript are considered to be objects. I will explain why.

A quick recap lecture, outlining that there are multiple [[Prototype]] objects in a chain, which is probably why it causes so much confusion for developers.

The constructor property is a property that references the constructor function that created the object. Heh? Basically, before ES6, it was only used if you wanted to see what function created the object. But ever since ES6, JavaScript uses the property internally for a few object types.

JavaScript's constructor property is useful because it returns a reference to the function that created an object instance. This allows for tracking the origin of objects and is essential in prototypal inheritance, where it helps establish the prototype chain

It's good to recap. That's why I've put together this short test that we can do together. enjoy!

The writable flag on the .prototype property is true, meaning that we can overwrite a function's prototype.

In this lecture I want you to take a step back and see for yourself how far you've come and what you've learnt.

Pat yourself on the back.

As you'll see, the gpDoctor object inherits properties and methods from its [[Prototype]] property. Importantly, objects you create will not have access to their constructor functions [[Prototype]]. This is important. Objects you create will only have access to its constructor functions .prototype property.

Got it? 

Let's go.

I want to prove to you that all data types in JavaScript (including strings, booleans, numbers, arrays, functions, etc.) inherit from the global Object.prototype property.

It is perhaps this reason that many developers refer to JavaScript as an Object Oriented Programming language.

The [[Prototype]] of an object, and a function's .prototype, serve two different purposes.

The [[Prototype]] of an object is used by the JavaScript engine to find properties and methods that an object can access.

On the other hand, the .prototype of a function is used to assign or create the [[Prototype]] object that your new object will be able to access.

Pretty neat, huh?

I know we covered this in the previous lecture, but I want to emphasize again that the [[Prototype]] and .prototype are two different things, each having its own objective.

Firstly, well done for sticking with me through this entire section. SERIOUSLY!

In this lecture I'll summarize what I think are the most important aspects to remember about the function's .prototype property.

Almost all functions have a .prototype property that can be used to create your own prototype chains.

Way back in Section 1 of this course, I gave you a hypothetical example of a medical website that would require different types of objects.

In this section I want you to apply your knowledge gained in this course to set up objects with custom prototypes.

Before the introduction of Object.create(), developers had to use the 'new' keyword to set up custom prototype chains.

In this lecture we will finish off our example of creating a prototypal chain using the 'new' keyword.

A quick summary of the 3 largest problems with using the 'new' keyword to set our prototypal chain.

In this lecture we will fix the incorrect constructor reference. Remember, the constructor property of an object is a reference to the function that created it. You can change this property to another function by assigning it to a new value. It's important to note that amending the constructor property of a function can be dangerous. This is because it can lead to unexpected behavior. For example, if you amend the constructor property of a function to a function that has different properties or methods, the behavior of the function may change unexpectedly. However, in our example we don't need to worry about this because we know what we're doing.

The Object.create() was introduced in 2011, and it's a method takes two arguments: the first argument is the prototype object, and the second argument is an object literal that defines the properties of the new object. We will only need to use the first argument in this example.

Object.create() is an improvement over using the new keyword, because at least this time we have a way to not duplicated properties inside of the VerifiedMember() function. But it's still not perfect, as we still overriding the entire .prototype property and therefore the constructor property gets messed up.

Although using Object.create() is an improvement over using the new keyword, it still suffers a few problems.

The Object.setPrototypeOf() method is a newer way to set the [[Prototype]] of a functions.prototype in JavaScript.

Caveat: even though we are talking "classes", keep reminding yourself that JavaScript is not a class-based language in the true meaning of the word.

What I'm trying to say is that "classes" in JavaScript are just syntactic sugar around using prototypes.

Like prototypes, the class syntax in JavaScript is used to define a class, which is a blueprint for creating objects. A class can have properties, methods, and constructors.

In order to create prototypal chains with classes, you need to know about the "extends" keyword.

The extends keyword in JavaScript is used to create a child class of another class (the parent class). The child class inherits all the properties and methods from the parent class. This is a powerful feature that allows you to reuse code and create more complex and sophisticated classes.

It's now time to step it up a notch, by using what you've learned to create a custom 3 tier prototype chain.

In this lecture we will convert the code of our previous Constructor Functions to one using Classes.

If you take a look at our code, you'll notice that we have a lot of duplicated properties, specifically the name and age properties.

This can pose problems, especially if you have larger code that is more complex.

The call() method is found on all Functions in JavaScript.

It is used to execute a function with a given this value and arguments provided individually. This means that you can use the call() method to call a method belonging to another object.

You can use the call() method to further improve code and to streamline your prototypal inheritance chains.

In the previous lecture you are well aware of the call() method, and how we can use that to effectively execute another function and pass in the derived object as the THIS keyword.

It's now time to finish off our entire project example.

Good luck.

I want to now do the exact same thing as the previous lecture, but convert the code into the newer Class syntax that was introduced by ES6.

A summary of what we've done in this section

At this point in time you have created a structure whereby: 

• you can create a User object

• you can create a VerifiedMember object, that inherits from the User

• you can create a Doctor, that inherits from a Verified Member

As a personal project, why don't you try and create a Patient object, that inherits from the VerifiedMember object? Good luck.

At this point you've come a far way.

Well done.

The concept of prototypes and classes are obsessed with ... OBJECTS.

Creating objects, and dealing with data inside of objects is the basis of programming. Programming is all about dealing with data.

And this is where the difference lies in prototype based languages versus classes. They differ in how they set up and deal with objects.

A key concept of any OOP based language is how they deal with inheritance. After all, programming should be efficient, which means that any language should try really hard at creating ways where objects can inherit properties and methods from each other, which not only saves time but also memory space.

Theory is boring, which is why I want to show you how a common class-based language (Java) can output text to a console, versus how a prototypal-based language (like JavaScript) can achieve the same thing.

The console for Java and JavaScript are not the same thing.

We've seen a simple example of displaying text to a console, but now I want to show you how inheritance works with Java.

JDoodle is an online coding platform and IDE for coding in Java, C, C++, PHP, Python, Ruby, Perl and other languages. In this video I'll show you how to execute Java Code from VSC, as well as how to use JDoodle.

You've come a long way. You know that a prototype-based language uses the concept of the "prototype" chain to find properties on objects, whereas in a class-based languages, everything is done via classes and sub-classes.

You'll hear a lot of developers talk about prototype based languages versus class-based languages, but few understand the practical differences.

You've come a long way. At this point you should be able to use what you've learnt in a practical and fun way.

At this point in the course, I could stop!

You might be thinking that defining your own objects using prototypes is the ONLY way to code. Well I'm sorry to burst your bubble, but in the development world, there is rarely one right solution. Sometimes, it may be better to set up your code using composition approach, rather than a prototypal based approach.

Let me explain more in this video.

In this lecture I'll show you how you could convert our previous code into a composition-based setup.

There are broadly speaking two ways to create and reuse objects in JavaScript - inheritance and composition.

You've done it! You've stuck with me through this entire course. WELL DONE. In this final summary, I want to explain what you've learnt in this section, and specifically when you may want to design your code using prototypes versus using composition.