System Design (LLD)The IS-A Relationship

The IS-A Relationship: When and Why to Use Inheritance

LevelIntermediate

Duration50 mins

TopicThe IS-A Relationship

3 / 4

Common Inheritance Mistakes

Learning from the Mistakes of Others

The history of object-oriented programming is littered with inheritance disasters—class hierarchies that seemed reasonable at the time but evolved into unmaintainable nightmares. The good news? These mistakes tend to follow predictable patterns. By studying them, you can develop the instincts to recognize and avoid them before they take root in your codebase.

Every experienced engineer has made these mistakes. The difference between good and great engineers is often just that great engineers learned from their mistakes (and the mistakes of others) faster.

This page catalogs the most common and damaging inheritance anti-patterns. For each, we'll examine why developers fall into the trap, what goes wrong, and how to restructure the design correctly.

What You Will Learn

By the end of this page, you will recognize the warning signs of inappropriate inheritance before you write the code. You'll understand the root causes of common mistakes and have concrete alternative designs ready to apply when you encounter these situations.

Mistake #1: Inheriting for Code Reuse Alone

The most common inheritance mistake is using it purely as a code-sharing mechanism, ignoring whether an IS-A relationship actually exists.

The thought process:

"Class B needs some methods that Class A already has. If B extends A, I get those methods for free!"

Why it's tempting:

Immediate code reuse with zero effort
The compiler accepts it without complaint
Tests pass (initially)
Faster implementation

code_reuse_mistake
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
// ❌ BAD: Inheritance for code reuse without IS-A
 
class DatabaseConnection {
    protected connectionString: string;
    protected isConnected: boolean = false;
    
    connect(): void {
        console.log(`Connecting to ${this.connectionString}`);
        this.isConnected = true;
    }
    
    disconnect(): void {
        this.isConnected = false;
    }
    
    logActivity(message: string): void {
        console.log(`[DB] ${new Date().toISOString()}: ${message}`);
    }
}
 
// ❌ FileHandler extends DatabaseConnection just to get logging!
class FileHandler extends DatabaseConnection {
    private filePath: string;
    
    constructor(filePath: string) {
        super();
        this.filePath = filePath;
    }
    
    readFile(): string {
        this.logActivity(`Reading file: ${this.filePath}`);
        // Read file logic...
        return "file contents";
    }
    
    // 💥 Problem: FileHandler inherits connect(), disconnect()
    // These methods make NO SENSE for a file handler!
    // What does it mean to "disconnect" a file handler?
}
 
// Client code is now confused
function doWork(db: DatabaseConnection): void {
    db.connect();
    // ... work ...
    db.disconnect();
}
 
const fileHandler = new FileHandler("/path/to/file");
doWork(fileHandler); // Compiles! But semantically nonsensical.

What goes wrong:

FileHandler exposes connect() and disconnect() methods that make no sense
FileHandler can be passed to functions expecting DatabaseConnection, causing confusion
Future changes to DatabaseConnection may break FileHandler unexpectedly
The codebase becomes harder to understand—why does a file handler have database concepts?

The fix: Use composition instead.

code_reuse_fix
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
// ✅ GOOD: Composition for code reuse
 
class Logger {
    log(message: string): void {
        console.log(`[${new Date().toISOString()}]: ${message}`);
    }
}
 
class DatabaseConnection {
    private logger: Logger;
    private connectionString: string;
    private isConnected: boolean = false;
    
    constructor(connectionString: string, logger: Logger) {
        this.connectionString = connectionString;
        this.logger = logger;
    }
    
    connect(): void {
        this.logger.log(`Connecting to ${this.connectionString}`);
        this.isConnected = true;
    }
    
    disconnect(): void {
        this.isConnected = false;
    }
}
 
class FileHandler {
    private logger: Logger;
    private filePath: string;
    
    constructor(filePath: string, logger: Logger) {
        this.filePath = filePath;
        this.logger = logger;
    }
    
    readFile(): string {
        this.logger.log(`Reading file: ${this.filePath}`);
        return "file contents";
    }
    
    // No confusing connect()/disconnect() methods!
    // Clean, focused API.
}
 
// Both use Logger, but neither inherits from the other
const logger = new Logger();
const db = new DatabaseConnection("mysql://...", logger);
const file = new FileHandler("/path/to/file", logger);

The Rule

If you're considering inheritance primarily to reuse a few methods, stop. Ask yourself: "Does the IS-A relationship genuinely hold?" If you can't confidently say yes, use composition. Extract the shared code into a separate class and inject it where needed.

Mistake #2: The Square-Rectangle Trap (Mutable Constraint)

The Square-Rectangle problem is so fundamental to understanding inheritance that it has its own name. The mistake occurs when a mathematically true IS-A relationship ("a square is a rectangle") becomes behaviorally false due to mutability.

The core issue: Mathematics defines rectangles by their properties at a single moment. Object-oriented design defines objects by their behavior over time, including how they change.

square_rectangle_problem
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
// ❌ The Problem
 
class Rectangle {
    protected width: number;
    protected height: number;
    
    constructor(width: number, height: number) {
        this.width = width;
        this.height = height;
    }
    
    setWidth(width: number): void {
        this.width = width;
    }
    
    setHeight(height: number): void {
        this.height = height;
    }
    
    getArea(): number {
        return this.width * this.height;
    }
}
 
class Square extends Rectangle {
    constructor(side: number) {
        super(side, side);
    }
    
    // Must override to maintain square invariant
    setWidth(width: number): void {
        this.width = width;
        this.height = width;
    }
    
    setHeight(height: number): void {
        this.width = height;
        this.height = height;
    }
}
 
// The problem manifests here:
function doubleWidth(rect: Rectangle): void {
    const originalArea = rect.getArea();
    const originalWidth = originalArea / rect.getArea(); // Simplified
    
    rect.setWidth(rect.getWidth() * 2);
    
    // Expected: area doubled (if only width changes)
    // Actual for Square: area quadrupled (both dimensions changed)!
}
 
const square = new Square(5);
console.log(square.getArea()); // 25
 
doubleWidth(square);
// Expected: width=10, height=5, area=50
// Actual: width=10, height=10, area=100 💥

Why this is insidious:

Mathematically, a square IS a rectangle
The code compiles without errors
Individual unit tests of Square may pass
The bug only appears when Square is used polymorphically

Solutions:

Three Valid Approaches

•Make both immutable — No setters, only factory methods. If you can't change dimensions, the behavioral conflict disappears.
•Don't inherit — Make Square and Rectangle siblings extending abstract Shape, without Square extending Rectangle.
•Remove dimension setters from Rectangle — If Rectangle only exposes getArea() and no mutation, the conflict doesn't manifest.

The General Pattern

Whenever a subclass has a stricter invariant than its parent, and the parent allows mutations that would violate that invariant, you have a Square-Rectangle trap. Watch for phrases like "X is a Y, but with an additional constraint on..."

Mistake #3: Restricting Inherited Behavior

A child class that throws "not supported" exceptions or makes inherited methods do nothing is almost always a design error. This pattern has a name: the "Refused Bequest" code smell.

Why it happens:

Developers want "most" of the parent's behavior
Just one or two methods don't apply to the child
It seems easier to just stub them out than to redesign

restricting_behavior
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
// ❌ BAD: Restricting inherited behavior
 
class Stack<T> {
    protected items: T[] = [];
    
    push(item: T): void {
        this.items.push(item);
    }
    
    pop(): T | undefined {
        return this.items.pop();
    }
    
    peek(): T | undefined {
        return this.items[this.items.length - 1];
    }
    
    // Additional utility methods
    insertAt(index: number, item: T): void {
        this.items.splice(index, 0, item);
    }
    
    removeAt(index: number): T | undefined {
        return this.items.splice(index, 1)[0];
    }
}
 
// ❌ "Queue" that inherits Stack and refuses some behaviors
class Queue<T> extends Stack<T> {
    // Override push to be enqueue (okay so far)
    enqueue(item: T): void {
        this.items.unshift(item);
    }
    
    // Use pop() as dequeue (okay)
    dequeue(): T | undefined {
        return this.pop();
    }
    
    // ❌ PROBLEM: Refuse insertAt because queues don't allow it
    insertAt(index: number, item: T): void {
        throw new Error("Queues don't support arbitrary insertion");
    }
    
    // ❌ PROBLEM: Refuse removeAt
    removeAt(index: number): T | undefined {
        throw new Error("Queues don't support arbitrary removal");
    }
    
    // Also: what about push() and peek()? Are they valid for Queue?
}
 
// Code expecting a Stack will break with Queue
function reorderStack<T>(stack: Stack<T>): void {
    const temp = stack.removeAt(0); // 💥 Throws for Queue!
    stack.insertAt(2, temp!);        // 💥 Throws for Queue!
}

Why this is wrong:

Violates Liskov Substitution Principle—Queue can't substitute for Stack
Creates runtime errors instead of compile-time safety
Forces callers to know about the specific subclass
Makes the inheritance hierarchy misleading

The fix: Recognize that Stack and Queue are peers, not parent-child. Both implement a more general abstraction.

correct_hierarchy
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
// ✅ GOOD: Correct hierarchy
 
interface Collection<T> {
    add(item: T): void;
    remove(): T | undefined;
    peek(): T | undefined;
    isEmpty(): boolean;
}
 
class Stack<T> implements Collection<T> {
    private items: T[] = [];
    
    add(item: T): void {
        this.items.push(item);
    }
    
    remove(): T | undefined {
        return this.items.pop();
    }
    
    peek(): T | undefined {
        return this.items[this.items.length - 1];
    }
    
    isEmpty(): boolean {
        return this.items.length === 0;
    }
    
    // Stack-specific methods (not in interface)
    pushMultiple(items: T[]): void {
        this.items.push(...items);
    }
}
 
class Queue<T> implements Collection<T> {
    private items: T[] = [];
    
    add(item: T): void {
        this.items.push(item);
    }
    
    remove(): T | undefined {
        return this.items.shift();
    }
    
    peek(): T | undefined {
        return this.items[0];
    }
    
    isEmpty(): boolean {
        return this.items.length === 0;
    }
    
    // Queue-specific methods (not in interface)
    priorityAdd(item: T, priority: number): void {
        this.items.splice(priority, 0, item);
    }
}
 
// Now code written against Collection works with both
function processCollection<T>(collection: Collection<T>): void {
    while (!collection.isEmpty()) {
        console.log(collection.remove());
    }
    // No exceptions! Both Stack and Queue work correctly.
}

Mistake #4: God Parent Classes

A God Parent Class is a base class that tries to provide everything any child might ever need. It accumulates functionality over time until it becomes a bloated, coupled, unmaintainable monster.

How it happens:

Start with a reasonable base class
Child A needs a utility method—add it to base class for "reuse"
Child B needs another method—add to base for "consistency"
Repeat until the base class has 50+ methods and 20+ fields
Every change to base class ripples to all children

god_parent
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
// ❌ BAD: God Parent Class
 
abstract class BaseController {
    // Authentication - needed by some controllers
    protected currentUser: User | null = null;
    protected isAuthenticated(): boolean { /* ... */ }
    protected requireAuth(): void { /* ... */ }
    protected hasPermission(perm: string): boolean { /* ... */ }
    
    // Logging - added for convenience
    protected logger: Logger;
    protected logInfo(msg: string): void { /* ... */ }
    protected logError(msg: string, err: Error): void { /* ... */ }
    protected logDebug(msg: string): void { /* ... */ }
    
    // Caching - needed by some performance-critical controllers
    protected cache: Cache;
    protected getCached<T>(key: string): T | null { /* ... */ }
    protected setCached<T>(key: string, value: T): void { /* ... */ }
    protected invalidateCache(key: string): void { /* ... */ }
    
    // Validation - used by form controllers
    protected validateRequired(val: any): boolean { /* ... */ }
    protected validateEmail(val: string): boolean { /* ... */ }
    protected validatePhone(val: string): boolean { /* ... */ }
    protected validationErrors: string[] = [];
    
    // Response formatting - for API controllers
    protected jsonResponse(data: any): Response { /* ... */ }
    protected errorResponse(msg: string): Response { /* ... */ }
    protected htmlResponse(template: string): Response { /* ... */ }
    
    // Transaction management - for DB controllers
    protected beginTransaction(): void { /* ... */ }
    protected commit(): void { /* ... */ }
    protected rollback(): void { /* ... */ }
    
    // Event dispatching - for some async controllers
    protected dispatch(event: Event): void { /* ... */ }
    protected subscribe(handler: EventHandler): void { /* ... */ }
    
    // And on and on...
    // 💥 Many children don't need most of these!
}
 
class SimpleHelloController extends BaseController {
    // Only needs logInfo, but inherits 30+ methods and 10+ fields
    handle(): Response {
        this.logInfo("Hello endpoint called");
        return this.jsonResponse({ message: "Hello" });
    }
}

Problems with God Parents:

Children inherit capabilities they don't need (bloat)
Hard to understand what each child actually uses
Changes to base class have unpredictable ripple effects
Testing requires mocking unused dependencies
Violates Single Responsibility Principle
Makes the inheritance hierarchy meaningless

The Fix: Composition + Focused Abstractions

•Extract services — Move logging, caching, auth, etc. into separate service classes
•Inject dependencies — Controllers receive only the services they need
•Use interfaces — Define small, focused interfaces for each capability
•Keep base classes minimal — If you have a base class, it should have very few members

Mistake #5: Deep Inheritance Hierarchies

Deep inheritance hierarchies (more than 2-3 levels) create significant maintenance and understanding challenges. Each additional level amplifies the coupling problems of inheritance.

Why deep hierarchies form:

Desire for increasing specialization
Fear of duplication ("I'll just extend this class")
Not recognizing when composition should replace inheritance
Modeling real-world taxonomies too literally

deep_hierarchy
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
// ❌ BAD: Deep inheritance hierarchy
 
// Level 1
abstract class Entity {
    id: string;
    createdAt: Date;
}
 
// Level 2
abstract class Auditable extends Entity {
    updatedAt: Date;
    updatedBy: string;
}
 
// Level 3
abstract class Nameable extends Auditable {
    name: string;
    slug: string;
}
 
// Level 4
abstract class Categorizable extends Nameable {
    category: Category;
    tags: Tag[];
}
 
// Level 5
abstract class Publishable extends Categorizable {
    publishedAt: Date | null;
    status: 'draft' | 'published' | 'archived';
}
 
// Level 6
abstract class ContentItem extends Publishable {
    body: string;
    author: User;
}
 
// Level 7
class BlogPost extends ContentItem {
    featuredImage: string;
    comments: Comment[];
}
 
// Now imagine:
// - Understanding what fields BlogPost has requires reading 7 classes
// - A change to Auditable affects 6 levels of children
// - Testing BlogPost requires understanding the entire hierarchy
// - New requirement: "Some entities need versioning" - where to add?

Problems Scale with Hierarchy Depth
Problem	2 Levels	4 Levels	7 Levels
Classes to understand	2	4	7
Potential change ripple	1 child	3 children	6 children
Debugging complexity	Low	Medium	High
Chance of diamond problem*	None	Possible	Likely
Flexibility for new requirements	Good	Moderate	Poor

Rule of thumb: If your hierarchy is deeper than 2-3 levels, question each level. Ask:

Is this intermediate class ever instantiated directly?
Is there code that uses this intermediate type polymorphically?
Could composition achieve the same reuse with less coupling?

Often, deep hierarchies can be flattened by using composition or mixins/traits for the cross-cutting concerns.

Mistake #6: The Yo-Yo Problem

The Yo-Yo Problem occurs when understanding a class requires bouncing up and down the inheritance hierarchy, because behavior is scattered across multiple levels.

The experience:

You look at ChildMethod() and see it calls this.parentHelper()
You go up to ParentHelper() and see it calls this.grandparentSetup()
You go up more and see it calls this.childCallback() (back down!)
The callback modifies state that affects parentHelper()
You've lost track of where you are...

This cognitive yo-yo is exhausting and error-prone.

yoyo_problem
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
// ❌ BAD: Yo-Yo inheritance
 
abstract class GrandparentProcessor {
    protected data: any;
    
    process(): void {
        this.initialize();      // Defined here
        this.validate();        // Abstract - defined in child
        this.transform();       // Defined in Parent
        this.finalize();        // Abstract - defined in grandchild
    }
    
    protected initialize(): void {
        this.data = this.getData(); // Abstract - defined in grandchild
        this.setupHooks();           // Defined in parent
    }
    
    protected abstract getData(): any;
    protected abstract validate(): void;
    protected abstract setupHooks(): void;
    protected abstract finalize(): void;
}
 
abstract class ParentProcessor extends GrandparentProcessor {
    protected hooks: Function[] = [];
    
    protected transform(): void {
        for (const hook of this.hooks) {
            this.data = hook(this.data);
        }
        this.afterTransform(); // Abstract - in grandchild
    }
    
    protected setupHooks(): void {
        this.hooks = this.getHooks(); // Abstract - in grandchild
    }
    
    protected abstract afterTransform(): void;
    protected abstract getHooks(): Function[];
}
 
class ConcreteProcessor extends ParentProcessor {
    protected getData(): any { return { value: 1 }; }
    protected validate(): void { /* validate this.data */ }
    protected finalize(): void { /* save this.data */ }
    protected afterTransform(): void { /* log result */ }
    protected getHooks(): Function[] { return [x => x.value * 2]; }
}
 
// To understand what process() does, you must:
// 1. Read GrandparentProcessor.process()
// 2. Jump to ConcreteProcessor.getData()
// 3. Back to ParentProcessor.setupHooks()
// 4. Jump to ConcreteProcessor.getHooks()
// 5. Back to ParentProcessor.validate()
// ... and so on, bouncing constantly

Avoid the Yo-Yo

Each class should be comprehensible by reading primarily that class. If understanding a method requires jumping between multiple inheritance levels, consider using Template Method pattern sparingly, favoring Strategy pattern (composition), or flattening the hierarchy.

Recognition Patterns: Red Flags

Here's a summary of red flags that indicate inheritance mistakes are present or imminent:

Red Flags for Inheritance Mistakes

•"I just need those few methods" — Inheriting for code reuse alone
•throw new NotSupportedException() — Restricting inherited behavior
•"X is a Y, but with constraints" — Square-rectangle trap
•Base class with 20+ methods — God parent anti-pattern
•4+ levels of inheritance — Deep hierarchy smell
•Constant up-down code navigation — Yo-yo problem
•"this child is a special case" — Probably not a valid IS-A
•Empty override methods — Behavior restriction in disguise
•Type checks in parent class — if (this instanceof Child) — broken abstraction
•Fear of changing base class — Too much coupled to it

Page Complete

You now recognize the most common inheritance mistakes: code-reuse-only inheritance, the Square-Rectangle trap, behavior restriction, god parents, deep hierarchies, and yo-yo code. In the final page, we'll explore how inheritance should be used to model behavioral hierarchies rather than just achieve code reuse.

3 / 4

Loading learning content...

System Design (LLD)The IS-A Relationship

The IS-A Relationship: When and Why to Use Inheritance

LevelIntermediate

Duration50 mins

TopicThe IS-A Relationship

3 / 4

Common Inheritance Mistakes

Learning from the Mistakes of Others

This page catalogs the most common and damaging inheritance anti-patterns. For each, we'll examine why developers fall into the trap, what goes wrong, and how to restructure the design correctly.

What You Will Learn

Mistake #1: Inheriting for Code Reuse Alone

The most common inheritance mistake is using it purely as a code-sharing mechanism, ignoring whether an IS-A relationship actually exists.

The thought process:

"Class B needs some methods that Class A already has. If B extends A, I get those methods for free!"

Why it's tempting:

Immediate code reuse with zero effort
The compiler accepts it without complaint
Tests pass (initially)
Faster implementation

code_reuse_mistake
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
// ❌ BAD: Inheritance for code reuse without IS-A
 
class DatabaseConnection {
    protected connectionString: string;
    protected isConnected: boolean = false;
    
    connect(): void {
        console.log(`Connecting to ${this.connectionString}`);
        this.isConnected = true;
    }
    
    disconnect(): void {
        this.isConnected = false;
    }
    
    logActivity(message: string): void {
        console.log(`[DB] ${new Date().toISOString()}: ${message}`);
    }
}
 
// ❌ FileHandler extends DatabaseConnection just to get logging!
class FileHandler extends DatabaseConnection {
    private filePath: string;
    
    constructor(filePath: string) {
        super();
        this.filePath = filePath;
    }
    
    readFile(): string {
        this.logActivity(`Reading file: ${this.filePath}`);
        // Read file logic...
        return "file contents";
    }
    
    // 💥 Problem: FileHandler inherits connect(), disconnect()
    // These methods make NO SENSE for a file handler!
    // What does it mean to "disconnect" a file handler?
}
 
// Client code is now confused
function doWork(db: DatabaseConnection): void {
    db.connect();
    // ... work ...
    db.disconnect();
}
 
const fileHandler = new FileHandler("/path/to/file");
doWork(fileHandler); // Compiles! But semantically nonsensical.

What goes wrong:

FileHandler exposes connect() and disconnect() methods that make no sense
FileHandler can be passed to functions expecting DatabaseConnection, causing confusion
Future changes to DatabaseConnection may break FileHandler unexpectedly
The codebase becomes harder to understand—why does a file handler have database concepts?

The fix: Use composition instead.

code_reuse_fix
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
// ✅ GOOD: Composition for code reuse
 
class Logger {
    log(message: string): void {
        console.log(`[${new Date().toISOString()}]: ${message}`);
    }
}
 
class DatabaseConnection {
    private logger: Logger;
    private connectionString: string;
    private isConnected: boolean = false;
    
    constructor(connectionString: string, logger: Logger) {
        this.connectionString = connectionString;
        this.logger = logger;
    }
    
    connect(): void {
        this.logger.log(`Connecting to ${this.connectionString}`);
        this.isConnected = true;
    }
    
    disconnect(): void {
        this.isConnected = false;
    }
}
 
class FileHandler {
    private logger: Logger;
    private filePath: string;
    
    constructor(filePath: string, logger: Logger) {
        this.filePath = filePath;
        this.logger = logger;
    }
    
    readFile(): string {
        this.logger.log(`Reading file: ${this.filePath}`);
        return "file contents";
    }
    
    // No confusing connect()/disconnect() methods!
    // Clean, focused API.
}
 
// Both use Logger, but neither inherits from the other
const logger = new Logger();
const db = new DatabaseConnection("mysql://...", logger);
const file = new FileHandler("/path/to/file", logger);

The Rule

Mistake #2: The Square-Rectangle Trap (Mutable Constraint)

The core issue: Mathematics defines rectangles by their properties at a single moment. Object-oriented design defines objects by their behavior over time, including how they change.

square_rectangle_problem
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
// ❌ The Problem
 
class Rectangle {
    protected width: number;
    protected height: number;
    
    constructor(width: number, height: number) {
        this.width = width;
        this.height = height;
    }
    
    setWidth(width: number): void {
        this.width = width;
    }
    
    setHeight(height: number): void {
        this.height = height;
    }
    
    getArea(): number {
        return this.width * this.height;
    }
}
 
class Square extends Rectangle {
    constructor(side: number) {
        super(side, side);
    }
    
    // Must override to maintain square invariant
    setWidth(width: number): void {
        this.width = width;
        this.height = width;
    }
    
    setHeight(height: number): void {
        this.width = height;
        this.height = height;
    }
}
 
// The problem manifests here:
function doubleWidth(rect: Rectangle): void {
    const originalArea = rect.getArea();
    const originalWidth = originalArea / rect.getArea(); // Simplified
    
    rect.setWidth(rect.getWidth() * 2);
    
    // Expected: area doubled (if only width changes)
    // Actual for Square: area quadrupled (both dimensions changed)!
}
 
const square = new Square(5);
console.log(square.getArea()); // 25
 
doubleWidth(square);
// Expected: width=10, height=5, area=50
// Actual: width=10, height=10, area=100 💥

Why this is insidious:

Mathematically, a square IS a rectangle
The code compiles without errors
Individual unit tests of Square may pass
The bug only appears when Square is used polymorphically

Solutions:

Three Valid Approaches

•Make both immutable — No setters, only factory methods. If you can't change dimensions, the behavioral conflict disappears.
•Don't inherit — Make Square and Rectangle siblings extending abstract Shape, without Square extending Rectangle.
•Remove dimension setters from Rectangle — If Rectangle only exposes getArea() and no mutation, the conflict doesn't manifest.

The General Pattern

Mistake #3: Restricting Inherited Behavior

A child class that throws "not supported" exceptions or makes inherited methods do nothing is almost always a design error. This pattern has a name: the "Refused Bequest" code smell.

Why it happens:

Developers want "most" of the parent's behavior
Just one or two methods don't apply to the child
It seems easier to just stub them out than to redesign

restricting_behavior
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
// ❌ BAD: Restricting inherited behavior
 
class Stack<T> {
    protected items: T[] = [];
    
    push(item: T): void {
        this.items.push(item);
    }
    
    pop(): T | undefined {
        return this.items.pop();
    }
    
    peek(): T | undefined {
        return this.items[this.items.length - 1];
    }
    
    // Additional utility methods
    insertAt(index: number, item: T): void {
        this.items.splice(index, 0, item);
    }
    
    removeAt(index: number): T | undefined {
        return this.items.splice(index, 1)[0];
    }
}
 
// ❌ "Queue" that inherits Stack and refuses some behaviors
class Queue<T> extends Stack<T> {
    // Override push to be enqueue (okay so far)
    enqueue(item: T): void {
        this.items.unshift(item);
    }
    
    // Use pop() as dequeue (okay)
    dequeue(): T | undefined {
        return this.pop();
    }
    
    // ❌ PROBLEM: Refuse insertAt because queues don't allow it
    insertAt(index: number, item: T): void {
        throw new Error("Queues don't support arbitrary insertion");
    }
    
    // ❌ PROBLEM: Refuse removeAt
    removeAt(index: number): T | undefined {
        throw new Error("Queues don't support arbitrary removal");
    }
    
    // Also: what about push() and peek()? Are they valid for Queue?
}
 
// Code expecting a Stack will break with Queue
function reorderStack<T>(stack: Stack<T>): void {
    const temp = stack.removeAt(0); // 💥 Throws for Queue!
    stack.insertAt(2, temp!);        // 💥 Throws for Queue!
}

Why this is wrong:

Violates Liskov Substitution Principle—Queue can't substitute for Stack
Creates runtime errors instead of compile-time safety
Forces callers to know about the specific subclass
Makes the inheritance hierarchy misleading

The fix: Recognize that Stack and Queue are peers, not parent-child. Both implement a more general abstraction.

correct_hierarchy
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
// ✅ GOOD: Correct hierarchy
 
interface Collection<T> {
    add(item: T): void;
    remove(): T | undefined;
    peek(): T | undefined;
    isEmpty(): boolean;
}
 
class Stack<T> implements Collection<T> {
    private items: T[] = [];
    
    add(item: T): void {
        this.items.push(item);
    }
    
    remove(): T | undefined {
        return this.items.pop();
    }
    
    peek(): T | undefined {
        return this.items[this.items.length - 1];
    }
    
    isEmpty(): boolean {
        return this.items.length === 0;
    }
    
    // Stack-specific methods (not in interface)
    pushMultiple(items: T[]): void {
        this.items.push(...items);
    }
}
 
class Queue<T> implements Collection<T> {
    private items: T[] = [];
    
    add(item: T): void {
        this.items.push(item);
    }
    
    remove(): T | undefined {
        return this.items.shift();
    }
    
    peek(): T | undefined {
        return this.items[0];
    }
    
    isEmpty(): boolean {
        return this.items.length === 0;
    }
    
    // Queue-specific methods (not in interface)
    priorityAdd(item: T, priority: number): void {
        this.items.splice(priority, 0, item);
    }
}
 
// Now code written against Collection works with both
function processCollection<T>(collection: Collection<T>): void {
    while (!collection.isEmpty()) {
        console.log(collection.remove());
    }
    // No exceptions! Both Stack and Queue work correctly.
}

Mistake #4: God Parent Classes

A God Parent Class is a base class that tries to provide everything any child might ever need. It accumulates functionality over time until it becomes a bloated, coupled, unmaintainable monster.

How it happens:

Start with a reasonable base class
Child A needs a utility method—add it to base class for "reuse"
Child B needs another method—add to base for "consistency"
Repeat until the base class has 50+ methods and 20+ fields
Every change to base class ripples to all children

god_parent
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
// ❌ BAD: God Parent Class
 
abstract class BaseController {
    // Authentication - needed by some controllers
    protected currentUser: User | null = null;
    protected isAuthenticated(): boolean { /* ... */ }
    protected requireAuth(): void { /* ... */ }
    protected hasPermission(perm: string): boolean { /* ... */ }
    
    // Logging - added for convenience
    protected logger: Logger;
    protected logInfo(msg: string): void { /* ... */ }
    protected logError(msg: string, err: Error): void { /* ... */ }
    protected logDebug(msg: string): void { /* ... */ }
    
    // Caching - needed by some performance-critical controllers
    protected cache: Cache;
    protected getCached<T>(key: string): T | null { /* ... */ }
    protected setCached<T>(key: string, value: T): void { /* ... */ }
    protected invalidateCache(key: string): void { /* ... */ }
    
    // Validation - used by form controllers
    protected validateRequired(val: any): boolean { /* ... */ }
    protected validateEmail(val: string): boolean { /* ... */ }
    protected validatePhone(val: string): boolean { /* ... */ }
    protected validationErrors: string[] = [];
    
    // Response formatting - for API controllers
    protected jsonResponse(data: any): Response { /* ... */ }
    protected errorResponse(msg: string): Response { /* ... */ }
    protected htmlResponse(template: string): Response { /* ... */ }
    
    // Transaction management - for DB controllers
    protected beginTransaction(): void { /* ... */ }
    protected commit(): void { /* ... */ }
    protected rollback(): void { /* ... */ }
    
    // Event dispatching - for some async controllers
    protected dispatch(event: Event): void { /* ... */ }
    protected subscribe(handler: EventHandler): void { /* ... */ }
    
    // And on and on...
    // 💥 Many children don't need most of these!
}
 
class SimpleHelloController extends BaseController {
    // Only needs logInfo, but inherits 30+ methods and 10+ fields
    handle(): Response {
        this.logInfo("Hello endpoint called");
        return this.jsonResponse({ message: "Hello" });
    }
}

Problems with God Parents:

Children inherit capabilities they don't need (bloat)
Hard to understand what each child actually uses
Changes to base class have unpredictable ripple effects
Testing requires mocking unused dependencies
Violates Single Responsibility Principle
Makes the inheritance hierarchy meaningless

The Fix: Composition + Focused Abstractions

•Extract services — Move logging, caching, auth, etc. into separate service classes
•Inject dependencies — Controllers receive only the services they need
•Use interfaces — Define small, focused interfaces for each capability
•Keep base classes minimal — If you have a base class, it should have very few members

Mistake #5: Deep Inheritance Hierarchies

Deep inheritance hierarchies (more than 2-3 levels) create significant maintenance and understanding challenges. Each additional level amplifies the coupling problems of inheritance.

Why deep hierarchies form:

Desire for increasing specialization
Fear of duplication ("I'll just extend this class")
Not recognizing when composition should replace inheritance
Modeling real-world taxonomies too literally

deep_hierarchy
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
// ❌ BAD: Deep inheritance hierarchy
 
// Level 1
abstract class Entity {
    id: string;
    createdAt: Date;
}
 
// Level 2
abstract class Auditable extends Entity {
    updatedAt: Date;
    updatedBy: string;
}
 
// Level 3
abstract class Nameable extends Auditable {
    name: string;
    slug: string;
}
 
// Level 4
abstract class Categorizable extends Nameable {
    category: Category;
    tags: Tag[];
}
 
// Level 5
abstract class Publishable extends Categorizable {
    publishedAt: Date | null;
    status: 'draft' | 'published' | 'archived';
}
 
// Level 6
abstract class ContentItem extends Publishable {
    body: string;
    author: User;
}
 
// Level 7
class BlogPost extends ContentItem {
    featuredImage: string;
    comments: Comment[];
}
 
// Now imagine:
// - Understanding what fields BlogPost has requires reading 7 classes
// - A change to Auditable affects 6 levels of children
// - Testing BlogPost requires understanding the entire hierarchy
// - New requirement: "Some entities need versioning" - where to add?

Problems Scale with Hierarchy Depth
Problem	2 Levels	4 Levels	7 Levels
Classes to understand	2	4	7
Potential change ripple	1 child	3 children	6 children
Debugging complexity	Low	Medium	High
Chance of diamond problem*	None	Possible	Likely
Flexibility for new requirements	Good	Moderate	Poor

Rule of thumb: If your hierarchy is deeper than 2-3 levels, question each level. Ask:

Is this intermediate class ever instantiated directly?
Is there code that uses this intermediate type polymorphically?
Could composition achieve the same reuse with less coupling?

Often, deep hierarchies can be flattened by using composition or mixins/traits for the cross-cutting concerns.

Mistake #6: The Yo-Yo Problem

The Yo-Yo Problem occurs when understanding a class requires bouncing up and down the inheritance hierarchy, because behavior is scattered across multiple levels.

The experience:

You look at ChildMethod() and see it calls this.parentHelper()
You go up to ParentHelper() and see it calls this.grandparentSetup()
You go up more and see it calls this.childCallback() (back down!)
The callback modifies state that affects parentHelper()
You've lost track of where you are...

This cognitive yo-yo is exhausting and error-prone.

yoyo_problem
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
// ❌ BAD: Yo-Yo inheritance
 
abstract class GrandparentProcessor {
    protected data: any;
    
    process(): void {
        this.initialize();      // Defined here
        this.validate();        // Abstract - defined in child
        this.transform();       // Defined in Parent
        this.finalize();        // Abstract - defined in grandchild
    }
    
    protected initialize(): void {
        this.data = this.getData(); // Abstract - defined in grandchild
        this.setupHooks();           // Defined in parent
    }
    
    protected abstract getData(): any;
    protected abstract validate(): void;
    protected abstract setupHooks(): void;
    protected abstract finalize(): void;
}
 
abstract class ParentProcessor extends GrandparentProcessor {
    protected hooks: Function[] = [];
    
    protected transform(): void {
        for (const hook of this.hooks) {
            this.data = hook(this.data);
        }
        this.afterTransform(); // Abstract - in grandchild
    }
    
    protected setupHooks(): void {
        this.hooks = this.getHooks(); // Abstract - in grandchild
    }
    
    protected abstract afterTransform(): void;
    protected abstract getHooks(): Function[];
}
 
class ConcreteProcessor extends ParentProcessor {
    protected getData(): any { return { value: 1 }; }
    protected validate(): void { /* validate this.data */ }
    protected finalize(): void { /* save this.data */ }
    protected afterTransform(): void { /* log result */ }
    protected getHooks(): Function[] { return [x => x.value * 2]; }
}
 
// To understand what process() does, you must:
// 1. Read GrandparentProcessor.process()
// 2. Jump to ConcreteProcessor.getData()
// 3. Back to ParentProcessor.setupHooks()
// 4. Jump to ConcreteProcessor.getHooks()
// 5. Back to ParentProcessor.validate()
// ... and so on, bouncing constantly

Avoid the Yo-Yo

Recognition Patterns: Red Flags

Here's a summary of red flags that indicate inheritance mistakes are present or imminent:

Red Flags for Inheritance Mistakes

•"I just need those few methods" — Inheriting for code reuse alone
•throw new NotSupportedException() — Restricting inherited behavior
•"X is a Y, but with constraints" — Square-rectangle trap
•Base class with 20+ methods — God parent anti-pattern
•4+ levels of inheritance — Deep hierarchy smell
•Constant up-down code navigation — Yo-yo problem
•"this child is a special case" — Probably not a valid IS-A
•Empty override methods — Behavior restriction in disguise
•Type checks in parent class — if (this instanceof Child) — broken abstraction
•Fear of changing base class — Too much coupled to it

Page Complete

3 / 4