Explain how prototypal inheritance differs from classical inheritance.

Q: Explain how prototypal inheritance differs from classical inheritance.

**Target Audience:** Engineers preparing for JavaScript object-model interview questions that expect a comparison to classical OOP. **Difficulty:** Hard > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . Every result below was actually run on Node.js v24.19.0 — the printed output is real, captured output, not illustrative sample text. This doc leads with the CONCEPTUAL DIFFERENCE from classical inheritance; for how the JavaScript prototype mechanism itself works, see Explain prototypal inheritance. ## 1. The Core Distinction, Up Front 📌 **Interview term:** **classical inheritance** (Java, C++, C#) is a **blueprint-and-instance** model -- a class is a fixed template, resolved at compile time, and every object is stamped out from a class, with its shape and methods fixed the moment it is created. 📌 **Interview term:

The problem

Question presented to candidate: "How does the way inheritance works in JavaScript actually differ from classical, class-based inheritance in a language like Java or C++?"

What a strong answer should cover:

Classical inheritance is a blueprint-and-instance model: a class is a fixed template, checked and fixed at compile time, and objects are stamped out from it.
Prototypal inheritance is an object-to-object delegation model: there are no blueprints -- objects link directly to other live objects, and lookup happens dynamically at runtime.
Delegation vs copying: a prototypal object does not receive a private copy of its prototype's methods -- it looks them up live, every time, by following a real link.
Dynamic vs static: a JavaScript prototype can be patched or extended after instances already exist, and every existing instance picks up the change immediately -- a compiled Java class cannot be altered at runtime.
Even JavaScript's class keyword does not introduce true classical inheritance underneath -- it is syntax sugar over the exact same prototype chain, and a class's methods remain a live, mutable object (Ctor.prototype) that can still be patched after the fact.

Clarifying questions expected:

"Should I focus on the conceptual difference, or also cover exactly how the JavaScript prototype mechanism itself works?" (the mechanism has its own dedicated question)

Code / implementation expected: Yes -- a runnable snippet proving a class's prototype is still live and patchable after declaration, unlike a compiled classical class.

prototypes
inheritance
oop
classes

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for JavaScript object-model interview questions that expect a comparison to classical OOP. Difficulty: Hard

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. Every result below was actually run on Node.js v24.19.0 — the printed output is real, captured output, not illustrative sample text. This doc leads with the CONCEPTUAL DIFFERENCE from classical inheritance; for how the JavaScript prototype mechanism itself works, see Explain prototypal inheritance.

1. The Core Distinction, Up Front

📌 Interview term: classical inheritance (Java, C++, C#) is a blueprint-and-instance model -- a class is a fixed template, resolved at compile time, and every object is stamped out from a class, with its shape and methods fixed the moment it is created.

📌 Interview term: **pr

The solution is hidden so you can try first

7 min read · 7 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptA class prototype stays a live, patchable object -- even after existing instances are created (run directly)