TypeScript 22 🔷 Inheritance and Polymorphism - KandZ

Inheritance is how one class reuses and extends another — a child class gets the parent’s members and can add or override them. Polymorphism is what that enables at use time — the same call behaves differently depending on the actual object, without the caller knowing or caring which subclass it is. Together they’re the backbone of object-oriented TypeScript. Inheritance saves duplication; polymorphism lets you write code against a base type and have it work correctly for every subtype. The two work as a pair, and understanding how they interact in TypeScript — with structural typing, access modifiers, and the override keyword — is what makes them useful rather than fragile.

Key point: Inheritance is the mechanism — class B extends A. Polymorphism is the payoff — a function that takes A and works correctly when passed a B. TypeScript adds three things to the classic model: override for explicit overrides, access modifiers (protected) that interact with inheritance, and structural typing that lets unrelated classes satisfy the same interface. Inheritance and polymorphism are powerful, but composition is often a better default.

What inheritance is

Inheritance lets a class acquire the members of another class and add or change them.

class Animal {
  constructor(public name: string) {}

  speak(): string {
    return `${this.name} makes a sound`;
  }
}

class Dog extends Animal {
  speak(): string {
    return `${this.name} barks`;
  }

  fetch(): string {
    return `${this.name} fetches the ball`;
  }
}

Dog extends Animal. Dog inherits name and can add fetch(). It overrides speak() — the subclass version replaces the parent’s.

What inheritance gives you:

Reuse — the parent’s members are available without re-declaring
Extension — the child adds new members
Override — the child replaces a member
super — access the parent’s constructor and methods

What the child gets:

Member	Access
`public` properties and methods	✅ inherited
`protected` members	✅ inherited
`private` members	❌ not accessible (but exist)
`readonly` members	✅ inherited
Static members	✅ inherited

The super keyword: Used to call the parent’s constructor and to call overridden methods.

class Dog extends Animal {
  constructor(name: string, public breed: string) {
    super(name);                  // call parent constructor first
  }

  speak(): string {
    return `${super.speak()} — specifically, a bark`;
  }
}

super() must be called before accessing this in a subclass constructor. super.method() calls the parent’s version of an overridden method.

Single inheritance: A class can extend only one parent. That’s the classic model. Multiple inheritance is not supported in TypeScript or JavaScript.

Why inheritance exists: It models “is-a” relationships. A Dog is an Animal. A SavingsAccount is an Account. When the relationship is genuine, inheritance lets you write the shared logic once and specialize it. The trap is using it for “has-a” relationships or for pure code reuse — those lead to fragile hierarchies.

Overriding methods

A subclass can override a parent method. TypeScript requires you to mark it explicitly with override if noImplicitOverride is enabled (part of some strict configs).

class Animal {
  speak(): string {
    return 'generic sound';
  }
}

class Dog extends Animal {
  override speak(): string {
    return 'woof';
  }
}

The override keyword says “I’m intentionally replacing a parent method.” Without it, TypeScript flags the method as suspicious — it might be a typo or an accidental shadow.

Why override matters: If you rename the parent method, the child’s method no longer overrides anything. Without override, it silently becomes a new method — a bug. With override, TypeScript errors, catching the mistake.

class Animal {
  speak(): string { return 'sound'; }
}

class Dog extends Animal {
  override speek(): string {   // ❌ typo — no such method in parent
    return 'woof';
  }
}

The typo fails to compile with override. Without it, speek would be silently added as a new method, and calls to speak() would use the parent’s version.

Return type rules: An override must return the same type or a subtype (covariance).

class Base {
  get(): Animal { return new Animal('x'); }
}

class Sub extends Base {
  override get(): Dog { return new Dog('y', 'lab'); }  // ✅ Dog is an Animal
}

Parameter rules: An override must accept the same parameters or wider (contravariance).

class Base {
  process(x: string | number): void { }
}

class Sub extends Base {
  override process(x: string): void { }  // ❌ too narrow — must accept string | number
}

TypeScript enforces these rules under strictFunctionTypes. They ensure a subclass can be used wherever the parent is expected.

Why overriding rules are strict: If a subclass could narrow parameters or widen return types, code written against the parent would break when given the subclass. The rules enforce the Liskov Substitution Principle — a subclass must be usable anywhere the parent is. TypeScript checks this at compile time.

What polymorphism is

Polymorphism is the ability to use a subclass through its parent’s type. A function that takes Animal works with a Dog without knowing it’s a Dog.

class Animal {
  constructor(public name: string) {}
  speak(): string { return `${this.name} makes a sound`; }
}

class Dog extends Animal {
  override speak(): string { return `${this.name} barks`; }
}

class Cat extends Animal {
  override speak(): string { return `${this.name} meows`; }
}

function describe(animal: Animal): string {
  return animal.speak();   // calls the actual subclass version
}

describe(new Dog('Rex'));  // "Rex barks"
describe(new Cat('Felix'));// "Felix meows"

describe accepts any Animal. When called with a Dog, animal.speak() runs the Dog version. When called with a Cat, it runs the Cat version. The function doesn’t know which — and doesn’t need to.

This is dynamic dispatch: the method called depends on the object’s actual type at runtime, not the declared type of the variable.

Two forms of polymorphism:

Subtype polymorphism — using a subclass through its parent’s type (what we just saw)
Parametric polymorphism — generics; a function that works for many types

TypeScript supports both. Subtype polymorphism is about class hierarchies; parametric polymorphism is about generics.

Why polymorphism matters: It lets you write general code that works with many specific types. Instead of if (animal instanceof Dog) { ... } else if (...) everywhere, you call animal.speak() and let the object decide. That’s cleaner, extensible, and easier to maintain.

Why “poly” — many, “morph” — forms: The same call takes many forms depending on the object. speak() means one thing to a Dog and another to a Cat, but the caller writes the same code. That uniformity is the value — add a new subclass, and existing code works without changes.

Polymorphism with interfaces

Polymorphism works with interfaces too — often more cleanly than with class hierarchies.

interface Shape {
  area(): number;
}

class Circle implements Shape {
  constructor(private radius: number) {}
  area(): number { return Math.PI * this.radius ** 2; }
}

class Square implements Shape {
  constructor(private side: number) {}
  area(): number { return this.side ** 2; }
}

function totalArea(shapes: Shape[]): number {
  return shapes.reduce((sum, s) => sum + s.area(), 0);
}

Circle and Square are unrelated — neither extends the other. Both implement Shape. The function works with any Shape, regardless of class hierarchy.

Why this is often better: Interfaces decouple the contract from the implementation. Any object with area() works — including plain objects, mocks in tests, or classes from other libraries. Inheritance ties you to a single hierarchy; interfaces don’t.

Structural polymorphism: TypeScript’s structural typing means a class doesn’t even need to declare implements Shape — if it has area(): number, it satisfies the interface.

class Triangle {
  constructor(private base: number, private height: number) {}
  area(): number { return (this.base * this.height) / 2; }
}

const t: Shape = new Triangle(3, 4);  // ✅ structurally compatible

Triangle never declared implements Shape, but it matches the shape, so it works.

Why interface polymorphism is idiomatic: It’s more flexible and less coupled. Inheritance-based polymorphism requires the classes to be related; interface-based polymorphism works for any class with the right shape. When you just need “a thing that does X,” an interface is the tool.

The Liskov Substitution Principle

The Liskov Substitution Principle (LSP) is the rule that makes polymorphism safe: a subclass must be usable anywhere its parent is, without breaking behavior.

What it means in practice:

class Rectangle {
  constructor(public width: number, public height: number) {}
  area(): number { return this.width * this.height; }
}

class Square extends Rectangle {
  constructor(side: number) {
    super(side, side);
  }

  setWidth(w: number): void {
    this.width = w;
    this.height = w;  // must maintain square-ness
  }
}

Is Square a valid subclass of Rectangle? The classic answer is no — because code that expects a Rectangle might set width and height independently, and Square breaks that contract.

function test(r: Rectangle) {
  r.setWidth(5);
  r.setHeight(4);
  console.log(r.area());  // expects 20
}

test(new Rectangle(0, 0));  // 20 ✅
test(new Square(0));         // 16 ❌ — broke the contract

The violation: Square changed the meaning of setWidth and setHeight. Code that relied on Rectangle‘s behavior fails with Square. That’s a LSP violation.

Why it matters in TypeScript: TypeScript’s type checker can’t catch LSP violations — they’re about behavior, not types. But violating LSP is a real bug source. The rule: if a subclass can’t honor the parent’s contract, it shouldn’t extend the parent.

Alternatives: Use composition. A Square might not be a Rectangle in the substitutable sense — it’s a shape that happens to have a side. Model it as a separate shape or a common interface instead.

Why LSP is subtle: The type system says Square extends Rectangle is valid — Square has all of Rectangle‘s members. But the behavior breaks. LSP is a design principle, not a compiler rule. It’s the mental discipline that keeps inheritance safe.

The fragile base class problem

Inheritance creates tight coupling. A change to the parent can break every subclass — often in ways that are hard to predict.

class Base {
  save(): void {
    this.validate();
    // write to disk
  }

  protected validate(): void {
    // basic validation
  }
}

class Derived extends Base {
  override validate(): void {
    // extended validation that assumes save() behavior
  }
}

If Base.save() is later changed to call validate() twice, or to call it in a different order, Derived might break — even though it wasn’t changed.

The problem: Subclasses depend on the parent’s implementation details, not just its contract. This coupling makes hierarchies fragile.

The mitigation: Design base classes carefully, document what’s overridable, and prefer composition when possible.

The principle: “Favor composition over inheritance.” Instead of subclassing, have a class hold a reference to another class that provides the behavior.

// Composition instead of inheritance
class Engine {
  start(): void { }
}

class Car {
  constructor(private engine: Engine) {}

  start(): void {
    this.engine.start();
  }
}

Car doesn’t extend Engine — it has one. Changing Engine doesn’t break Car the way a parent change would. The coupling is looser.

Why composition is often better: Inheritance is a strong relationship — subclasses are permanently tied to the parent. Composition is a weak relationship — the parts can change independently. For “has-a” relationships, composition is the right model; for “is-a” relationships, inheritance can work. Most modern design favors composition.

Inheritance vs composition

The choice between them is one of the most important in object-oriented design.

Aspect	Inheritance	Composition
Relationship	“is-a”	“has-a”
Coupling	Tight	Loose
Reuse	Parent’s code	Delegated behavior
Flexibility	Single parent	Multiple parts
Fragility	Base class changes	Parts independent
Testability	Hard to isolate	Easy to mock
Typical use	Genuine hierarchies	Shared behavior

When inheritance fits:

A genuine “is-a” relationship (Dog is an Animal)
Shared state and lifecycle
A framework that expects subclassing (e.g., Error)
Template method pattern — a base class defines an algorithm and subclasses fill in steps

When composition fits:

“Has-a” or “uses-a” relationships
Reusing behavior from unrelated parts
Avoiding the fragile base class problem
Multiple sources of behavior
Testability matters

A rule of thumb: Start with composition. Reach for inheritance only when the “is-a” relationship is genuine and the hierarchy is stable. Deep hierarchies are a smell; wide, flat compositions are usually better.

Why composition has won in modern practice: Deep inheritance hierarchies are hard to reason about, hard to refactor, and fragile. Composition lets you build systems from independent, testable parts. React, functional programming, and modern OOP all favor composition. Inheritance still has its place — but it’s no longer the default.

A full example

A document processing system showing inheritance, polymorphism, and the trade-offs.

// ============================================
// ABSTRACT BASE CLASS
// ============================================

abstract class Document {
  protected readonly id: string;
  protected readonly createdAt: Date;

  constructor(public readonly title: string) {
    this.id = crypto.randomUUID();
    this.createdAt = new Date();
  }

  abstract render(): string;

  summary(): string {
    return `"${this.title}" (${this.render().length} chars)`;
  }
}

// ============================================
// SUBCLASSES — POLYMORPHISM
// ============================================

class MarkdownDocument extends Document {
  constructor(
    title: string,
    private content: string
  ) {
    super(title);
  }

  override render(): string {
    return this.content;
  }
}

class HtmlDocument extends Document {
  constructor(
    title: string,
    private body: string
  ) {
    super(title);
  }

  override render(): string {
    return `<html><body>${this.body}</body></html>`;
  }

  stripTags(): string {
    return this.body.replace(/<[^>]*>/g, '');
  }
}

// ============================================
// POLYMORPHIC FUNCTION
// ============================================

function renderAll(docs: Document[]): void {
  for (const doc of docs) {
    console.log(doc.summary());
    console.log(doc.render());
  }
}

// ============================================
// INTERFACE-BASED POLYMORPHISM
// ============================================

interface Exportable {
  export(): string;
}

function exportDocs(items: Exportable[]): string[] {
  return items.map(i => i.export());
}

class PdfDocument extends Document implements Exportable {
  constructor(title: string, private pages: number) {
    super(title);
  }

  override render(): string {
    return `PDF with ${this.pages} pages`;
  }

  export(): string {
    return `exported:${this.title}.pdf`;
  }
}

// ============================================
// USAGE
// ============================================

const docs: Document[] = [
  new MarkdownDocument('README', '# Hello'),
  new HtmlDocument('Page', '<p>Hi</p>'),
  new PdfDocument('Report', 12)
];

renderAll(docs);

const exportables: Exportable[] = [
  new PdfDocument('Contract', 5)
];

console.log(exportDocs(exportables));

What this shows:

Document abstract base with shared state (id, createdAt, title) and an abstract render()
Subclasses override render() — subtype polymorphism
renderAll accepts Document[] and calls render() — dynamic dispatch
Exportable interface — separate contract for export behavior
PdfDocument implements both — multiple contracts

The caller uses Document and Exportable types. The actual behavior depends on the concrete class.

Why this shape: It’s realistic — different document types share metadata and expose different capabilities. Some are Document; some are also Exportable. Functions depend on the smallest contract they need. Inheritance shares metadata; interfaces share capabilities. Both work together.

Complete Example Session

# ============================================
# PART 1: BASIC INHERITANCE
# ============================================

cat > inherit.ts << 'EOF'
class Animal {
  constructor(public name: string) {}

  speak(): string {
    return `${this.name} makes a sound`;
  }
}

class Dog extends Animal {
  constructor(name: string, public breed: string) {
    super(name);
  }

  override speak(): string {
    return `${this.name} barks`;
  }

  fetch(): string {
    return `${this.name} (${this.breed}) fetches`;
  }
}

const d = new Dog('Rex', 'Lab');
console.log(d.speak());
console.log(d.fetch());
console.log(d.name);
EOF

npx tsc --noEmit inherit.ts
# (no errors)

# ============================================
# PART 2: POLYMORPHISM
# ============================================

cat > poly.ts << 'EOF'
class Animal {
  constructor(public name: string) {}
  speak(): string { return `${this.name} makes a sound`; }
}

class Dog extends Animal {
  override speak(): string { return `${this.name} barks`; }
}

class Cat extends Animal {
  override speak(): string { return `${this.name} meows`; }
}

function describe(a: Animal): string {
  return a.speak();   // dynamic dispatch
}

const animals: Animal[] = [
  new Dog('Rex'),
  new Cat('Felix'),
  new Animal('Generic')
];

for (const a of animals) console.log(describe(a));
EOF

npx tsc --noEmit poly.ts
# (no errors)

# ============================================
# PART 3: SUPER AND OVERRIDE
# ============================================

cat > super.ts << 'EOF'
class Animal {
  constructor(public name: string) {}
  speak(): string { return `${this.name} makes a sound`; }
}

class Dog extends Animal {
  override speak(): string {
    return `${super.speak()} (specifically, a bark)`;
  }
}

console.log(new Dog('Rex').speak());
EOF

npx tsc --noEmit super.ts
# (no errors)

# ============================================
# PART 4: OVERRIDE ERRORS
# ============================================

cat > override-errors.ts << 'EOF'
class Animal {
  speak(): string { return 'sound'; }
}

class Dog extends Animal {
  override speek(): string { return 'woof'; }  // ❌ typo
}
EOF

npx tsc --noEmit override-errors.ts
# [ override-errors.ts:6:12 - This member cannot have an 'override' modifier because it is not declared in the base class 'Animal'. ]

rm override-errors.ts

# ============================================
# PART 5: INTERFACE POLYMORPHISM
# ============================================

cat > iface.ts << 'EOF'
interface Shape {
  area(): number;
}

class Circle implements Shape {
  constructor(private r: number) {}
  area(): number { return Math.PI * this.r ** 2; }
}

class Square implements Shape {
  constructor(private s: number) {}
  area(): number { return this.s ** 2; }
}

// Structural — no implements needed
class Triangle {
  constructor(private b: number, private h: number) {}
  area(): number { return (this.b * this.h) / 2; }
}

function total(shapes: Shape[]): number {
  return shapes.reduce((sum, s) => sum + s.area(), 0);
}

console.log(total([
  new Circle(2),
  new Square(3),
  new Triangle(4, 5)
]));
EOF

npx tsc --noEmit iface.ts
# (no errors)

# ============================================
# PART 6: ABSTRACT CLASS + POLYMORPHISM
# ============================================

cat > doc.ts << 'EOF'
abstract class Document {
  constructor(public title: string) {}
  abstract render(): string;
  summary(): string { return `${this.title}: ${this.render()}`; }
}

class Markdown extends Document {
  constructor(title: string, private body: string) { super(title); }
  override render(): string { return this.body; }
}

class Html extends Document {
  constructor(title: string, private body: string) { super(title); }
  override render(): string { return `<p>${this.body}</p>`; }
}

const docs: Document[] = [
  new Markdown('A', '# hello'),
  new Html('B', 'hi')
];

for (const d of docs) console.log(d.summary());
EOF

npx tsc --noEmit doc.ts
# (no errors)

# ============================================
# PART 7: COMPILE AND RUN
# ============================================

npx tsc inherit.ts poly.ts super.ts iface.ts doc.ts
node inherit.js
# [ Rex barks ]
# [ Rex (Lab) fetches ]
# [ Rex ]

node poly.js
# [ Rex barks ]
# [ Felix meows ]
# [ Generic makes a sound ]

node super.js
# [ Rex makes a sound (specifically, a bark) ]

node iface.js
# [ 41.132741228718345 ]

node doc.js
# [ A: # hello ]
# [ B: <p>hi</p> ]

Quick Reference

Inheritance Syntax

Syntax	Purpose
`class B extends A { }`	Inherit from `A`
`super()`	Call parent constructor
`super.method()`	Call parent method
`override method()`	Override parent method
`class B extends A implements I { }`	Inherit and implement

Access in Subclasses

Member	Inherited?	Accessible?
`public`	✅	✅
`protected`	✅	✅
`private`	✅ exists	❌ not accessible
`readonly`	✅	✅ (read)
`static`	✅	✅ via class name
Constructor	✅	via `super()`

Override Rules

Rule	Detail
Use `override`	Required under `noImplicitOverride`
Return type	Same or subtype (covariant)
Parameters	Same or wider (contravariant)
Access modifier	Can’t narrow (`public` → `protected` ❌)
`super` access	Can call parent version

Polymorphism Types

Type	Mechanism
Subtype	Class hierarchy — `Dog` as `Animal`
Interface	Structural — any shape match
Parametric	Generics — `<T>`

`super` Rules

Rule	Detail
Call before `this`	Required in subclass constructor
Call once	Only one `super()` per constructor
Access parent method	`super.method()`
Access parent property	Not via `super` — use `this`

Liskov Substitution

Rule	Meaning
Behavioral	Subclass must honor parent’s contract
Return type	Covariant (narrower)
Parameters	Contravariant (wider)
Preconditions	Can’t strengthen
Postconditions	Can’t weaken

Inheritance vs Composition

Aspect	Inheritance	Composition
Relationship	“is-a”	“has-a”
Coupling	Tight	Loose
Flexibility	Single parent	Multiple parts
Fragility	High	Low
Testability	Harder	Easier
Default	❌	✅

When to Inherit

Fit	Not fit
Genuine “is-a”	“has-a”
Shared state + behavior	Pure code reuse
Template method	Unrelated classes
Framework subclassing	Deep hierarchies
Stable hierarchy	Rapidly changing base

Common Patterns

Pattern	Structure
Template method	Abstract class + hooks
Strategy	Interface + multiple impls
Factory	Static method returning subclass
Decorator	Composition wrapping
Adapter	Wrapper implementing target

Error Cases

Error	Cause
`Cannot access 'this' before super()`	`super()` not first
`must call super()`	Missing constructor `super()`
`is not declared in base class`	`override` without parent
`is not assignable`	LSP violation of return type
`Cannot override`	Modifier narrowing

Static Inheritance

Aspect	Behavior
Inherited	✅
Accessible via subclass	✅
`this` in static	Refers to subclass
Override	Possible but rare

Best Practices

✅ Do This:

// Use inheritance for genuine "is-a" relationships
class Dog extends Animal { }                              // ✅

// Mark overrides explicitly
override speak(): string { return 'woof'; }               // ✅

// Call super in constructors
constructor(name: string) {
  super(name);
  // ...
}                                                          // ✅

// Use protected for subclass-only access
protected log(msg: string): void { }                      // ✅

// Accept the base type in functions for polymorphism
function describe(a: Animal): string { return a.speak(); } // ✅

// Prefer interface polymorphism for decoupling
interface Shape { area(): number; }                       // ✅

// Favor composition for "has-a"
class Car {
  constructor(private engine: Engine) {}
}                                                          // ✅

// Keep hierarchies shallow
class Animal { }
class Dog extends Animal { }                              // ✅ (2 levels)

// Document overridable members
protected hook(): void { }                                // ✅

❌ Don’t Do This:

// Don't use inheritance for code reuse alone
class Utils extends MathHelpers { }  // ❌ "is-a" false        // ❌

// Don't forget override
speak(): string { return 'woof'; }  // ⚠️  silent override      // ⚠️

// Don't access this before super
constructor() {
  this.x = 1;  // ❌
  super();
}                                                          // ❌

// Don't use private when subclasses need access
class Base { private helper(): void { } }  // ⚠️  use protected // ⚠️

// Don't build deep hierarchies
class A extends B extends C extends D extends E { }        // ❌

// Don't narrow parameter types in overrides
override process(x: string): void { }  // ⚠️  must be wider   // ⚠️

// Don't break LSP
class Square extends Rectangle { }  // ⚠️  if behavior differs // ⚠️

// Don't use inheritance for mixins
class A extends B extends C { }  // ❌ can't combine behaviors  // ❌

Common Pitfalls

Pitfall	Problem	Solution
`this` before `super()`	Runtime/compile error	Call `super()` first
Missing `override`	Silent shadow	Add `override`
Private parent member	Inaccessible	Use `protected`
Narrowing override params	Compile error	Widen, don’t narrow
LSP violation	Runtime bugs	Honor parent contract
Deep hierarchies	Fragile, hard to reason	Prefer composition
Inheritance for reuse only	False “is-a”	Use composition
Overriding access modifier	Can’t narrow	Keep or widen
Forgetting static inheritance	Wrong `this`	Understand `this` in static
Single inheritance limits	Can’t combine	Use interfaces

Real-World Examples

1. Basic inheritance

class Animal { }
class Dog extends Animal { }

2. Subclass constructor with super

class Dog extends Animal {
  constructor(name: string) { super(name); }
}

3. Override method

class Dog extends Animal {
  override speak(): string { return 'woof'; }
}

4. Call parent method

class Dog extends Animal {
  override speak(): string {
    return `${super.speak()}!`;
  }
}

5. Protected member

class Base {
  protected log(msg: string): void { }
}

6. Polymorphic function

function speak(a: Animal): string { return a.speak(); }

7. Polymorphic array

const animals: Animal[] = [new Dog(), new Cat()];

8. Interface polymorphism

interface Shape { area(): number; }
function total(shapes: Shape[]): number { }

9. Structural compatibility

class Triangle { area(): number { return 0; } }
const s: Shape = new Triangle();  // ✅ if shape matches

10. Abstract + polymorphism

abstract class Shape {
  abstract area(): number;
}
function describe(s: Shape): string { }

11. Template method

abstract class Processor {
  process(): void {
    this.step1();
    this.step2();
  }
  protected abstract step1(): void;
  protected abstract step2(): void;
}

12. `instanceof` narrowing

function describe(a: Animal): string {
  if (a instanceof Dog) return a.fetch();
  return a.speak();
}

13. Mixin via composition

class Logger {
  log(msg: string): void { }
}
class Service {
  constructor(private logger: Logger) {}
}

14. Factory returning subclass

class Shape {
  static create(type: 'circle' | 'square'): Shape {
    return type === 'circle' ? new Circle() : new Square();
  }
}

15. Static inheritance

class Base {
  static name = 'base';
}
class Sub extends Base { }
Sub.name;  // inherited

16. Abstract with shared state

abstract class Entity {
  protected id = crypto.randomUUID();
  abstract save(): Promise<void>;
}

17. Multiple interfaces

class User implements Serializable, Comparable<User> { }

18. Covariant return

class Base { get(): Animal { } }
class Sub extends Base { override get(): Dog { } }  // ✅

19. Contravariant params

class Base { accept(x: string | number): void { } }
class Sub extends Base { override accept(x: string | number | boolean): void { } }  // ✅

20. Composition over inheritance

class Engine { start(): void { } }
class Car {
  constructor(private engine: Engine) {}
  start(): void { this.engine.start(); }
}

Visual: Inheritance

┌──────────────────────────────────────────────┐
│  class Animal                                │
│  ─ name                                      │
│  ─ speak()                                   │
│                                              │
└──────────────────────────────────────────────┘
                    ▲
                    │ extends
        ┌───────────┼───────────┐
        │                       │
┌───────────────┐      ┌──────────────┐
│  class Dog    │      │  class Cat   │
│  ─ breed      │      │  ─ indoor    │
│  ─ speak()    │      │  ─ speak()   │
│  ─ fetch()    │      │  ─ purr()    │
└───────────────┘      └──────────────┘

Dog is-a Animal
Cat is-a Animal

Visual: Polymorphism

┌──────────────────────────────────────────────┐
│  function describe(a: Animal): string {      │
│    return a.speak();                         │
│  }                                           │
│                                              │
└──────────────────────────────────────────────┘
                  │
                  │  called with
                  ▼
┌──────────────────────────────────────────────┐
│  describe(new Dog('Rex'))                    │
│  → animal is actually Dog                    │
│  → a.speak() runs Dog.speak()                │
│  → "Rex barks"                               │
│                                              │
│  describe(new Cat('Felix'))                  │
│  → animal is actually Cat                    │
│  → a.speak() runs Cat.speak()                │
│  → "Felix meows"                             │
│                                              │
│  Same call, different behavior               │
│                                              │
└──────────────────────────────────────────────┘

Visual: `super` Flow

┌──────────────────────────────────────────────┐
│  class Dog extends Animal {                  │
│    constructor(name: string) {               │
│      super(name);                            │
│      // ↑ runs Animal's constructor          │
│    }                                         │
│  }                                           │
│                                              │
└──────────────────────────────────────────────┘

┌──────────────────────────────────────────────┐
│  class Dog extends Animal {                  │
│    override speak() {                        │
│      return super.speak() + '!';             │
│      //     ↑ calls Animal.speak()           │
│    }                                         │
│  }                                           │
│                                              │
└──────────────────────────────────────────────┘

┌──────────────────────────────────────────────┐
│  Rules:                                      │
│  ─ super() before this in constructor        │
│  ─ only one super() call                     │
│  ─ super.method() for parent methods         │
│                                              │
└──────────────────────────────────────────────┘

Visual: Inheritance vs Composition

┌──────────────────────────────────────────────┐
│  Inheritance — "is-a"                        │
│                                              │
│  class Dog extends Animal { }                │
│                                              │
│  Dog gets all of Animal's members            │
│  Tightly coupled                             │
│  Single parent                               │
│                                              │
└──────────────────────────────────────────────┘

┌──────────────────────────────────────────────┐
│  Composition — "has-a"                       │
│                                              │
│  class Car {                                 │
│    constructor(private engine: Engine) {}    │
│  }                                           │
│                                              │
│  Car delegates to engine                     │
│  Loosely coupled                             │
│  Multiple parts                              │
│                                              │
└──────────────────────────────────────────────┘

Visual: Liskov Substitution

┌──────────────────────────────────────────────┐
│  class Rectangle {                           │
│    setWidth(w: number): void { }             │
│    setHeight(h: number): void { }            │
│  }                                           │
│                                              │
│  class Square extends Rectangle {            │
│    // setting width also sets height         │
│  }                                           │
│                                              │
└──────────────────────────────────────────────┘

┌──────────────────────────────────────────────┐
│  Code expecting Rectangle:                   │
│                                              │
│  r.setWidth(5);                              │
│  r.setHeight(4);                             │
│  area = 20  ← expects this                   │
│                                              │
│  With Square:                                │
│  area = 16  ← ❌ LSP violation               │
│                                              │
└──────────────────────────────────────────────┘

Visual: Override Rules

┌──────────────────────────────────────────────┐
│  Return type — covariant (narrower) ✅       │
│                                              │
│  Base: get(): Animal                         │
│  Sub:  get(): Dog                            │
│                                              │
│  Dog is assignable to Animal                 │
│                                              │
└──────────────────────────────────────────────┘

┌──────────────────────────────────────────────┐
│  Parameters — contravariant (wider) ✅       │
│                                              │
│  Base: accept(x: string)                     │
│  Sub:  accept(x: string | number)            │
│                                              │
│  Sub accepts more, not less                  │
│                                              │
└──────────────────────────────────────────────┘

┌──────────────────────────────────────────────┐
│  Modifier — can't narrow ❌                  │
│                                              │
│  Base: public method()                       │
│  Sub:  protected method()  ❌                │
│                                              │
│  Sub can't restrict access                   │
│                                              │
└──────────────────────────────────────────────┘

Visual: `override` Safety

┌──────────────────────────────────────────────┐
│  With `override`:                            │
│                                              │
│  class Dog extends Animal {                  │
│    override speek() { }                      │
│    // ❌ error — no 'speek' in Animal        │
│  }                                           │
│                                              │
│  Typo caught at compile time                 │
│                                              │
└──────────────────────────────────────────────┘

┌──────────────────────────────────────────────┐
│  Without `override`:                         │
│                                              │
│  class Dog extends Animal {                  │
│    speek() { }                               │
│    // ⚠️  silently added as new method       │
│  }                                           │
│                                              │
│  Calls to speak() use Animal's version       │
│  Bug hidden                                  │
│                                              │
└──────────────────────────────────────────────┘

Visual: Composition Chain

┌──────────────────────────────────────────────┐
│  Instead of deep inheritance:                │
│                                              │
│  class A extends B extends C extends D { }   │
│                                              │
│  Use composition:                            │
│                                              │
│  class Service {                             │
│    constructor(                              │
│      private logger: Logger,                 │
│      private db: Database,                   │
│      private cache: Cache                    │
│    ) {}                                      │
│  }                                           │
│                                              │
│  Each part is independent and testable       │
│                                              │
└──────────────────────────────────────────────┘

Visual: Decision Flow

┌──────────────────────────────────────────────┐
│  Is it a genuine "is-a" relationship?        │
│       │                                      │
│       ├── Yes ──► Stable hierarchy?          │
│       │            │                         │
│       │            ├── Yes ──► Inheritance   │
│       │            │                         │
│       │            └── No  ──► Composition   │
│       │                                      │
│       └── No ──► Composition                 │
│                                              │
└──────────────────────────────────────────────┘

┌──────────────────────────────────────────────┐
│  Do you need shared behavior?                │
│       │                                      │
│       ├── Yes ──► Template method (abstract) │
│       │                                      │
│       └── No ──► Interface + composition     │
│                                              │
└──────────────────────────────────────────────┘

Summary

Concept	Meaning
Inheritance	Subclass extends parent
`extends`	Inherit from a class
`super()`	Call parent constructor
`super.method()`	Call parent method
`override`	Explicit override marker
Polymorphism	Same call, different behavior
Subtype polymorphism	Use subclass as parent
Interface polymorphism	Use any matching shape
Covariant return	Narrower return type allowed
Contravariant params	Wider parameter type allowed
LSP	Subclass must be substitutable
Composition	“Has-a” instead of “is-a”

Key takeaways:

Inheritance lets a class extend another and reuse or override its members
extends is single inheritance — a class can have only one parent
super() must be called before this in a subclass constructor
override makes overriding explicit and catches typos
Polymorphism lets code use a subclass through its parent’s type
Dynamic dispatch calls the actual object’s method, not the declared type’s
Interface polymorphism is more flexible than class hierarchies — any matching shape works
Liskov Substitution — a subclass must honor the parent’s contract or it breaks callers
Return types can narrow (covariant); parameters can widen (contravariant)
The fragile base class problem — parent changes can break subclasses
Favor composition over inheritance — “has-a” is usually safer than “is-a”
Keep hierarchies shallow — deep inheritance is hard to reason about
Use inheritance for genuine is-a relationships and shared behavior; use interfaces and composition for everything else

Remember: Inheritance is a tool for expressing “is-a” relationships and sharing behavior across related classes. Polymorphism is what makes that hierarchy useful — the same call behaves differently per object, without the caller knowing. But inheritance creates tight coupling and fragile hierarchies. Use it deliberately, mark overrides explicitly, honor the Liskov Substitution Principle, and reach for composition when the relationship isn’t genuinely “is-a.” The result is code that’s easier to extend, test, and reason about.

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!