Inheritance / Polymorphism / Encapsulation / Abstraction


JavaScript is a bit confusing for developers experienced in class-based languages (like Java or C++), as it is dynamic and does not provide a class implementation per se (the class keyword is introduced in ES2015, but is syntactic sugar, JavaScript remains prototype-based).

When it comes to inheritance, JavaScript only has one construct: objects. Each object has a private property (referred to as [[Prototype]] ) which holds a link to another object called its prototype. That prototype object has a prototype of its own, and so on until an object is reached with null as its prototype. By definition, null has no prototype, and acts as the final link in this prototype chain.

Nearly all objects in JavaScript are instances of Object which sits on the top of a prototype chain. While this is often considered to be one of JavaScript’s weaknesses, the prototypal inheritance model is in fact more powerful than the classic model. It is, for example, fairly trivial to build a classic model on top of a prototypal model.


Poly= many, morphism=form or behavior shifting.

In programming, It is used when we want a function’s (let say function X’s) interface to be flexible enough to accept different types or number of parameters. Also, based on changing parameters types or numbers, we might want the function X to behave differently (morphism).

We write multiple implementations of X function where each implementation accepts different parameters types or number of parameters. Based on the type or number of parameter, the compiler (at runtime) decides which implementation of X should be executed when X is called from some code. JS is not a typed language so it really not meant to use OOP concepts like polymorphism. However, the newer version of JS now include classes and there is possibility that polymorphism could start making sense in JS, too. Other answers provide some interesting workarounds.


When you simply want to create an object just to store some data, and it is the only object of its kind, you can use an object literal and create your object. This is quite common and you will use this simple pattern often.

However, whenever you want to create objects with similar functionalities (to use the same methods and properties), you encapsulate the main functionalities in a Function and you use that Function’s constructor to create the objects. This is the essence of encapsulation. And it is this need for encapsulation that we are concerned with and why we are using the Combination Constructor/Prototype Pattern.

To make practical use of OOP in JavaScript, we will build an object-oriented quiz application that uses all the principles and techniques we learn in this article. First up, our quiz application will have users (a Users Function) who take the quiz. There will be some common properties for every user who takes the quiz: each user will have a name, a score, an email, and the quiz scores (all the scores). These are the properties of the User object. In addition, each User object should be able to show the name and score, save scores, and change the email. These are the methods of the object.

Because we want ALL the user objects to have these same properties and methods, we cannot use the object literal way of creating objects. We have to use a constructor Function to encapsulate these properties and methods.

Since we know all users will have the same set of properties, it makes sense to create a Function (Class in OOP languages) that encapsulates these properties and methods. Thus, we will use the Combination Constructor/Prototype Pattern for this.


Abstraction is one of the 3 pillars of Object Oriented Programming(OOP). It literally means to perceive an entity in a system or context from a particular perspective. We take out unnecessary details and only focus on aspects that are necessary to that context or system under consideration.

Here is some good explanation:

You as a person have different relationships in different roles. When you are at school, then you are a “Student”. When you are at work, you are an “Employee”. When you are at government institution, you can be viewed as a “Citizen”. So it boils down to what in what context are we looking at an entity/object. So if I am modelling a Payroll System, I will look at you as an Employee(PRN, Full Time/Part Time, Designation). If am modelling a Course Enrollment System, then I will consider your aspects and characteristics as a Student(Roll Number, Age, Gender, Course Enrolled). And if I am modelling a Social Security Information System then I will look at your details as a Citizen(like DOB, Gender, Country Of Birth, etc.)

Remember that Abstraction(focussing on necessary details) is different from Encapsulation(hiding details from the outer world). Encapsulation means hiding the details of the object and providing a decent interface for the entities in outer world to interact with that object or entity. For example, if someone want to know my name then he cannot directly access my brain cells to get to know what is my name. Instead that person will either ask my name. If a driver wants to speed up a vehicle then there is an interface(accelerator pedal, gear, etc) for that purpose.

Leave a Reply

Your email address will not be published. Required fields are marked *