DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • When Angular APIs Return 200 but the Frontend Is Already Failing Users
  • 5 Layers of Prompt Injection Defense You Can Wire Into Any Node.js App
  • Boosting React.js Development Productivity With Google Code Assist
  • Why Angular Performance Problems Are Often Backend Problems

Trending

  • Has AI-Generated SQL Impacted Data Quality? We Reviewed 1,000 Incidents
  • Can Claude Skills Replace Playwright Agents? A Practical View for QA Engineers
  • From Data Movement to Local Intelligence: The Shift from Centralized to Federated AI
  • Throughput vs Goodput: The Performance Metric You Are Probably Ignoring in LLM Testing
  1. DZone
  2. Coding
  3. JavaScript
  4. Classical Inheritance in JavaScript ES5

Classical Inheritance in JavaScript ES5

By 
Eli Bendersky user avatar
Eli Bendersky
·
Oct. 24, 13 · Interview
Likes (1)
Comment
Save
Tweet
Share
8.5K Views

Join the DZone community and get the full member experience.

Join For Free

JavaScript’s prototype-based inheritance is interesting and has its uses, but sometimes one just wants to express classical inheritance, familiar from C++ and Java. This need has been recognized by the ECMAScript committee and classes are being discussed for inclusion in the next version of the standard.

It was surprisingly hard for me to find a good and simple code sample that shows how to cleanly and correctly express inheritance with ES5 (a lot of links discuss how to implement the pre-ES5 tools required for that) and explains why the thing works. Mozilla’s Object.Create reference came close, but not quite there because it still left some open questions.

Hence this short post. Without further ado, the following code defines a parent class named Shape with a constructor and a method, and a derived class named Circle that has its own method:

// Shape - superclass
// x,y: location of shape's bounding rectangle
function Shape(x, y) {
  this.x = x;
  this.y = y;
}

// Superclass method
Shape.prototype.move = function(x, y) {
  this.x += x;
  this.y += y;
}

// Circle - subclass
function Circle(x, y, r) {
  // Call constructor of superclass to initialize superclass-derived members.
  Shape.call(this, x, y);

  // Initialize subclass's own members
  this.r = r;
}

// Circle derives from Shape
Circle.prototype = Object.create(Shape.prototype);
Circle.prototype.constructor = Circle;

// Subclass methods. Add them after Circle.prototype is created with
// Object.create
Circle.prototype.area = function() {
  return this.r * 2 * Math.PI;
}

The most interesting part here, the one that actually performs the feat of inheritance is these two lines, so I’ll explain them a bit:

Circle.prototype = Object.create(Shape.prototype);
Circle.prototype.constructor = Circle;

The first line is the magic – it sets up the prototype chain. To understand it, you must first understand that "the prototype of an object" and "the .prototype property of an object" are different things. If you don’t, go read on that a bit. The first line, interpreted very technically, says: the prototype of new objects created with the Circle constructor is an object whose prototype is the prototype of objects created by Shape constructor. Yeah, that’s a handful. But it can be simplified as: each Circle has a Shape as its prototype.

What about the second line? While not strictly necessary, it’s there to preserve some useful invariants, as we’ll see below. Since the assignment to Circle.prototype kills the existing Circle.prototype.constructor (which was set to Circle when the Circle constructor was created), we restore it.

Let’s whip up a JavaScript console and load that code inside, to quickly try some stuff:

> var shp = new Shape(1, 2)
undefined
> [shp.x, shp.y]
[1, 2]
> shp.move(1, 1)
undefined
> [shp.x, shp.y]
[2, 3]

… but we’re here for the circles:

> var cir = new Circle(5, 6, 2)
undefined
> [cir.x, cir.y, cir.r]
[5, 6, 2]
> cir.move(1, 1)
undefined
> [cir.x, cir.y, cir.r]
[6, 7, 2]
> cir.area()
12.566370614359172

So far so good, a Circle initialized itself correctly using the Shape constructor; it responds to the methods inherited from Shape, and to its own area method too.

Let’s check that the prototype shenanigans worked as expected:

> var shape_proto = Object.getPrototypeOf(shp)
undefined
> var circle_proto = Object.getPrototypeOf(cir)
undefined
> Object.getPrototypeOf(circle_proto) === shape_proto
true

Great. Now let’s see what instanceof has to say:

> cir instanceof Shape
true
> cir instanceof Circle
true
> shp instanceof Shape
true
> shp instanceof Circle
false

Finally, here are some things we can do with the constructor property that wouldn’t have been possible had we not preserved it:

> cir.constructor === Circle
true
  // Create a new Circle object based on an existing Circle instance
> var new_cir = new cir.constructor(3, 4, 1.5)
undefined
> new_cir
Circle {x: 3, y: 4, r: 1.5, constructor: function, area: function}

A lot of existing code (and programmers) expect the constructor property of objects to point back to the constructor function used to create them with new. In addition, it is sometimes useful to be able to create a new object of the same class as an existing object, and here as well the constructor property is useful.

So that is how we express classical inheritance in JavaScript. It is very explicit, and hence on the long-ish side. Hopefully the future ES standards will provide nice sugar for succinct class definitions.


Inheritance (object-oriented programming) JavaScript

Published at DZone with permission of Eli Bendersky. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • When Angular APIs Return 200 but the Frontend Is Already Failing Users
  • 5 Layers of Prompt Injection Defense You Can Wire Into Any Node.js App
  • Boosting React.js Development Productivity With Google Code Assist
  • Why Angular Performance Problems Are Often Backend Problems

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook