System Design (HLD)What Is Inheritance?

What Is Inheritance?

LevelBeginner

Duration55 mins

TopicWhat Is Inheritance?

4 / 4

Inheritance as Specialization

The Right Mental Model

Inheritance is often taught as a code reuse mechanism: 'Extend a class to inherit its functionality.' While technically accurate, this mental model leads developers astray. It encourages creating inheritance relationships for convenience rather than correctness.

The right mental model is specialization: a child class is a specialized version of its parent. The child represents a more specific concept within a broader category. A GermanShepherd is a specialized Dog. A CheckingAccount is a specialized BankAccount. A SportsCar is a specialized Car.

This page establishes specialization as the guiding principle for inheritance and explores how to apply it correctly.

What You Will Learn

By the end of this page, you'll understand inheritance as conceptual specialization, be able to distinguish appropriate from inappropriate hierarchies, and have clear principles for designing inheritance relationships that remain stable over time.

What is Specialization?

Specialization is the process of creating a more specific version of something while preserving its essential nature. A specialized entity:

Is still fundamentally what the general type is — A SportsCar is still a Car
Has all the characteristics of the general type — SportsCars have wheels, engines, steering
Adds additional, more specific characteristics — SportsCars have turbos, spoilers, better handling
May refine general behavior — SportsCars accelerate faster, but still accelerate

The hierarchy of concepts:

Specialization creates natural hierarchies in the real world and in software:

Vehicle (most general)
├── Car (more specific)
│   ├── SportsCar (even more specific)
│   │   └── Ferrari458 (very specific)
│   └── FamilyCar
├── Motorcycle
└── Truck

Each level adds specificity. Each child is a valid member of every ancestor category. A Ferrari458 is a SportsCar, is a Car, is a Vehicle.

The Specialization Test

Ask: 'Is every <Child> necessarily a <Parent>?' not 'Would it be convenient for <Child> to reuse <Parent>'s code?' The first question tests for genuine specialization. The second tests for code reuse, which doesn't justify inheritance.

The IS-A Relationship: Formalized

The IS-A test is the standard way to evaluate whether inheritance is appropriate. But the test is often applied too casually. Let's formalize it.

Strong IS-A (appropriate for inheritance):

An X IS-A Y if and only if:

Every instance of X can substitute for any instance of Y in any context

The substitution makes semantic sense in the domain

The relationship is permanent and unconditional

Weak IS-A (inappropriate for inheritance):

An X seems like a Y might apply when:

X shares some behavior with Y

X could be described using Y in some contexts

The relationship depends on interpretation or perspective

Strong IS-A vs. Weak IS-A Examples
Relationship	IS-A Type	Reasoning	Verdict
Dog IS-A Animal	Strong	Every dog is always an animal, in every context	✅ Inherit
Cat IS-A Pet	Weak	Not all cats are pets (wild cats). Context-dependent	❌ Avoid
Rectangle IS-A Shape	Strong	Every rectangle is always a shape	✅ Inherit
Square IS-A Rectangle	Weak*	Mathematically yes, but mutability creates issues (see LSP)	⚠️ Careful
Manager IS-A Employee	Strong	Every manager is always an employee	✅ Inherit
Customer IS-A Person	Weak	A customer is a role, not a permanent identity	❌ Avoid
SavingsAccount IS-A BankAccount	Strong	Every savings account is always a bank account	✅ Inherit
Stack IS-A ArrayList	Weak	Stack uses array-like storage, but isn't an array conceptually	❌ Avoid

The Square-Rectangle Problem

The classic pitfall: mathematically, a square IS-A rectangle. But if Rectangle has setWidth() and setHeight() that can set independent values, a Square can't honor this contract without breaking its invariant (equal sides). This teaches us: IS-A must hold for behavior, not just data.

Behavioral Specialization: More Than Data

True specialization involves behavioral compatibility, not just structural similarity. The child must honor the behavioral contract established by the parent.

What behavioral specialization means:

Behavioral Specialization Requirements

•Preconditions preserved or weakened — If parent's method requires positive numbers, child can accept any number (weaker) but not require only even numbers (stronger)
•Postconditions preserved or strengthened — If parent promises non-null return, child must also return non-null (can promise more, like 'always returns positive')
•Invariants preserved — If parent's balance is always non-negative, child must maintain this
•Exceptions compatible — Child can throw fewer or more specific exceptions, not new unrelated ones
•Side effects compatible — If parent doesn't modify global state, child shouldn't either

behavioral-specialization
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
67
68
69
70
71
// Parent establishes behavioral contracts
class Sorter {
    /**
     * Sorts the array in ascending order.
     * @param arr - The array to sort (will not be modified)
     * @returns A new sorted array
     * 
     * Contract:
     * - Precondition: arr is not null
     * - Postcondition: Returns non-null array with same elements, in ascending order
     * - Invariant: Original array is unchanged
     */
    public sort(arr: number[]): number[] {
        return [...arr].sort((a, b) => a - b);
    }
}
 
// GOOD specialization: honors all contracts
class StableSorter extends Sorter {
    /**
     * Sorts using a stable algorithm (equal elements stay in original order).
     * Strengthens postcondition: guaranteed stable sort.
     */
    public sort(arr: number[]): number[] {
        // Stable merge sort - satisfies parent's contract + adds guarantee
        return this.mergeSort([...arr]);
    }
    
    private mergeSort(arr: number[]): number[] {
        if (arr.length <= 1) return arr;
        const mid = Math.floor(arr.length / 2);
        const left = this.mergeSort(arr.slice(0, mid));
        const right = this.mergeSort(arr.slice(mid));
        return this.merge(left, right);
    }
    
    private merge(left: number[], right: number[]): number[] {
        const result: number[] = [];
        let l = 0, r = 0;
        while (l < left.length && r < right.length) {
            if (left[l] <= right[r]) result.push(left[l++]);
            else result.push(right[r++]);
        }
        return result.concat(left.slice(l), right.slice(r));
    }
}
 
// BAD specialization: violates contracts
class BrokenSorter extends Sorter {
    /**
     * PROBLEM: Modifies input array (violates invariant)
     * PROBLEM: Returns null for empty arrays (violates postcondition)
     */
    public sort(arr: number[]): number[] {
        if (arr.length === 0) return null!;  // ❌ Violates postcondition
        arr.sort((a, b) => a - b);            // ❌ Violates invariant
        return arr;
    }
}
 
// Usage showing why contracts matter
function processScores(sorter: Sorter, scores: number[]): void {
    const original = [...scores];
    const sorted = sorter.sort(scores);
    
    // These assertions should ALWAYS pass if sorter follows the contract
    console.assert(scores.join() === original.join(), "Original unchanged");
    console.assert(sorted !== null, "Never returns null");
    
    // BrokenSorter would fail both assertions!
}

Extension vs. Restriction: What Children Can Do

Specialization typically means extending the parent's capabilities, not restricting them. This is a crucial principle often violated.

Extension (appropriate):

The child adds new capabilities while preserving all parent capabilities.

Car extends Vehicle → adds doors, trunk
EmailNotification extends Notification → adds subject line
SportsPlayer extends Person → adds team, position, stats

Restriction (problematic):

The child removes or disables parent capabilities.

Penguin extends Bird → removes flying ability
ImmutableList extends List → adds but add/remove throw exceptions
DisabledButton extends Button → click does nothing

Extension (Good Specialization)

•Child can do everything parent can
•Child adds NEW methods
•Child refines or enhances parent methods
•Substitution works seamlessly
•No surprises for callers

Restriction (Bad Specialization)

•Child throws exceptions for valid parent operations
•Child silently ignores parent method calls
•Child has methods that 'don't apply'
•Substitution causes runtime errors
•Violates caller expectations

restriction-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
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
// The Classic "Penguin Problem"
 
class Bird {
    protected name: string;
    
    constructor(name: string) {
        this.name = name;
    }
    
    public fly(): void {
        console.log(`${this.name} is flying through the air!`);
    }
    
    public eat(): void {
        console.log(`${this.name} is eating.`);
    }
}
 
// ❌ BAD: Penguin restricts Bird's capabilities
class Penguin extends Bird {
    public fly(): void {
        // What do we do here?
        
        // Option 1: Throw exception (violates substitution)
        throw new Error("Penguins can't fly!");
        
        // Option 2: Do nothing (violates expected behavior)
        // console.log("Nothing happens...");  
        
        // Option 3: Waddle instead (changes semantics)
        // console.log(`${this.name} waddles on the ground`);
    }
}
 
// This is legal but leads to runtime problems
function migrateBirds(birds: Bird[]): void {
    for (const bird of birds) {
        bird.fly();  // Will crash for Penguins!
    }
}
 
// ✅ BETTER: Restructure the hierarchy
abstract class Bird2 {
    protected name: string;
    
    constructor(name: string) {
        this.name = name;
    }
    
    public abstract move(): void;  // All birds move somehow
    public eat(): void {
        console.log(`${this.name} is eating.`);
    }
}
 
class FlyingBird extends Bird2 {
    public move(): void {
        console.log(`${this.name} flies through the air`);
    }
    
    public fly(): void {
        this.move();  // Alias for clarity
    }
}
 
class FlightlessBird extends Bird2 {
    public move(): void {
        console.log(`${this.name} walks on the ground`);
    }
}
 
class Eagle extends FlyingBird {
    public soar(): void {
        console.log(`${this.name} soars on thermal currents`);
    }
}
 
class Penguin2 extends FlightlessBird {
    public swim(): void {
        console.log(`${this.name} swims gracefully`);
    }
}

The Restructuring Principle

When you find yourself needing to restrict parent functionality, it's usually a sign that the hierarchy is wrong. Ask: 'What do all these types have in common?' That commonality should be the parent. Introduce intermediate classes for capability groups.

Specialization in Domain Modeling

The best inheritance hierarchies model genuine domain concepts. They reflect how experts in the domain actually think about categories and specializations.

Domain-driven hierarchy design:

Listen to domain experts — How do they describe categories? What words do they use?
Look for 'kind of' language — 'An X is a kind of Y' often indicates true specialization
Test with substitution — Can domain experts use a child wherever they'd use a parent?
Watch for roles vs. types — A 'Customer' is a role a Person plays, not a specialization of Person

domain-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
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
// Example: Financial Instruments Domain
 
// Domain concept: All financial instruments share these characteristics
abstract class FinancialInstrument {
    protected readonly symbol: string;
    protected readonly issuedDate: Date;
    
    constructor(symbol: string, issuedDate: Date) {
        this.symbol = symbol;
        this.issuedDate = issuedDate;
    }
    
    public abstract getCurrentValue(): number;
    public abstract getDescription(): string;
}
 
// Specialization: Equity instruments (ownership stakes)
abstract class Equity extends FinancialInstrument {
    protected sharesOutstanding: number;
    
    constructor(symbol: string, issuedDate: Date, sharesOutstanding: number) {
        super(symbol, issuedDate);
        this.sharesOutstanding = sharesOutstanding;
    }
    
    public abstract getDividendYield(): number;
}
 
// Further specialization
class CommonStock extends Equity {
    private pricePerShare: number;
    private annualDividend: number;
    
    constructor(
        symbol: string, 
        issuedDate: Date, 
        sharesOutstanding: number,
        pricePerShare: number,
        annualDividend: number
    ) {
        super(symbol, issuedDate, sharesOutstanding);
        this.pricePerShare = pricePerShare;
        this.annualDividend = annualDividend;
    }
    
    public getCurrentValue(): number {
        return this.pricePerShare * this.sharesOutstanding;
    }
    
    public getDividendYield(): number {
        return this.annualDividend / this.pricePerShare;
    }
    
    public getDescription(): string {
        return `Common Stock: ${this.symbol}`;
    }
}
 
class PreferredStock extends Equity {
    private parValue: number;
    private fixedDividendRate: number;
    
    constructor(
        symbol: string,
        issuedDate: Date,
        sharesOutstanding: number,
        parValue: number,
        fixedDividendRate: number
    ) {
        super(symbol, issuedDate, sharesOutstanding);
        this.parValue = parValue;
        this.fixedDividendRate = fixedDividendRate;
    }
    
    public getCurrentValue(): number {
        return this.parValue * this.sharesOutstanding;
    }
    
    public getDividendYield(): number {
        return this.fixedDividendRate;  // Fixed rate, not calculated
    }
    
    public getDescription(): string {
        return `Preferred Stock: ${this.symbol} (${this.fixedDividendRate * 100}%)`;
    }
}
 
// Different branch of specialization: Debt instruments
abstract class Debt extends FinancialInstrument {
    protected principalAmount: number;
    protected interestRate: number;
    protected maturityDate: Date;
    
    constructor(
        symbol: string,
        issuedDate: Date,
        principalAmount: number,
        interestRate: number,
        maturityDate: Date
    ) {
        super(symbol, issuedDate);
        this.principalAmount = principalAmount;
        this.interestRate = interestRate;
        this.maturityDate = maturityDate;
    }
    
    public abstract getInterestPayment(): number;
}
 
class CorporateBond extends Debt {
    private creditRating: string;
    
    constructor(
        symbol: string,
        issuedDate: Date,
        principalAmount: number,
        interestRate: number,
        maturityDate: Date,
        creditRating: string
    ) {
        super(symbol, issuedDate, principalAmount, interestRate, maturityDate);
        this.creditRating = creditRating;
    }
    
    public getCurrentValue(): number {
        // Bond valuation based on rates, simplified here
        return this.principalAmount;
    }
    
    public getInterestPayment(): number {
        return this.principalAmount * this.interestRate;
    }
    
    public getDescription(): string {
        return `Corporate Bond: ${this.symbol} (Rating: ${this.creditRating})`;
    }
}
 
// Usage: Work with financial instruments polymorphically
function calculatePortfolioValue(instruments: FinancialInstrument[]): number {
    return instruments.reduce((sum, inst) => sum + inst.getCurrentValue(), 0);
}

Recognizing Bad Hierarchies

Experience teaches us to recognize inheritance relationships that will cause problems. Here are the warning signs:

Red Flags in Inheritance Design

•'Unused methods' smell — Child inherits methods it doesn't need or makes no sense to call. Example: 'Immutable list has add() method that throws.'
•'Role-based hierarchy' smell — Modeling roles as types. 'Customer extends Person' breaks when one person can be both customer and employee.
•'Convenience inheritance' smell — Child extends parent primarily for code reuse without genuine IS-A relationship.
•'Parallel hierarchies' smell — When one hierarchy exists primarily to mirror another: Shape/ShapeFactory, Document/DocumentRenderer.
•'God parent' smell — Parent class is too broad, too generic, or has too many children with unrelated characteristics.
•'Deep hierarchy' smell — Many levels of inheritance; changes at top ripple unpredictably; hard to understand where behavior comes from.
•'Override everything' smell — Children override almost all parent methods, indicating the parent's behavior doesn't really fit.

The Alternative: Composition

When you see these red flags, consider composition instead of inheritance. A Customer HAS-A PersonInfo rather than IS-A Person. A Stack HAS-A internal storage mechanism rather than IS-A ArrayList. Composition is more flexible and avoids these problems.

Design Principles for Specialization

Applying specialization correctly requires deliberate design. Here are actionable principles:

Specialization Design Principles

•Design parents for extension — Think about who will extend and how. Provide protected hooks. Document what's safe to override.
•Keep hierarchies shallow — Prefer 1-2 levels of inheritance. Deeper hierarchies are harder to understand and more fragile.
•Favor abstract parents — If a class is extended, it often shouldn't be instantiated directly. Make it abstract.
•Test substitutability — For each child, verify it works correctly in every context where parent is expected.
•Match domain concepts — The hierarchy should reflect domain reality, not implementation convenience.
•Use interfaces for capabilities — If you need 'mixin' behavior or horizontal categorization, use interfaces or composition.
•Document behavioral contracts — Make explicit what children must preserve when overriding.
•Prefer composition for code reuse — If the relationship isn't truly IS-A, use HAS-A instead.

good-hierarchy-example
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
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
/**
 * Example: Well-designed hierarchy following all principles
 */
 
// Abstract parent - designed for extension
abstract class PaymentProcessor {
    protected transactionLog: TransactionEntry[] = [];
    
    // Template method - defines the algorithm, not meant to be overridden
    public async processPayment(amount: number, details: PaymentDetails): Promise<PaymentResult> {
        // Validation (can be customized)
        const validation = await this.validatePayment(amount, details);
        if (!validation.valid) {
            return { success: false, error: validation.reason };
        }
        
        // Core processing (must be implemented)
        const result = await this.executePayment(amount, details);
        
        // Logging (can be customized)
        this.logTransaction(amount, details, result);
        
        return result;
    }
    
    // Override hook: customize validation
    protected async validatePayment(
        amount: number, 
        details: PaymentDetails
    ): Promise<ValidationResult> {
        // Default validation
        if (amount <= 0) {
            return { valid: false, reason: "Invalid amount" };
        }
        return { valid: true };
    }
    
    // Must be implemented by children
    protected abstract executePayment(
        amount: number, 
        details: PaymentDetails
    ): Promise<PaymentResult>;
    
    // Override hook: customize logging
    protected logTransaction(
        amount: number, 
        details: PaymentDetails, 
        result: PaymentResult
    ): void {
        this.transactionLog.push({
            timestamp: new Date(),
            amount,
            success: result.success,
        });
    }
}
 
// First specialization level
class CardPaymentProcessor extends PaymentProcessor {
    protected async executePayment(
        amount: number, 
        details: PaymentDetails
    ): Promise<PaymentResult> {
        // Card-specific implementation
        const cardDetails = details as CardPaymentDetails;
        // ... process card payment
        return { success: true, transactionId: "card_" + Date.now() };
    }
    
    protected async validatePayment(
        amount: number, 
        details: PaymentDetails
    ): Promise<ValidationResult> {
        // Card-specific validation + parent validation
        const baseResult = await super.validatePayment(amount, details);
        if (!baseResult.valid) return baseResult;
        
        const cardDetails = details as CardPaymentDetails;
        if (!this.isValidCardNumber(cardDetails.cardNumber)) {
            return { valid: false, reason: "Invalid card number" };
        }
        return { valid: true };
    }
    
    private isValidCardNumber(cardNumber: string): boolean {
        // Luhn algorithm check
        return cardNumber.length >= 13;
    }
}
 
// Capability via interface, not inheritance
interface RefundCapable {
    processRefund(transactionId: string, amount: number): Promise<PaymentResult>;
}
 
// Second specialization level (shallow hierarchy)
class RefundableCardProcessor extends CardPaymentProcessor implements RefundCapable {
    async processRefund(transactionId: string, amount: number): Promise<PaymentResult> {
        // Refund-specific logic
        return { success: true, transactionId: "refund_" + Date.now() };
    }
}
 
// Types used above
interface PaymentDetails {
    type: string;
}
 
interface CardPaymentDetails extends PaymentDetails {
    cardNumber: string;
    expiryDate: string;
    cvv: string;
}
 
interface PaymentResult {
    success: boolean;
    transactionId?: string;
    error?: string;
}
 
interface ValidationResult {
    valid: boolean;
    reason?: string;
}
 
interface TransactionEntry {
    timestamp: Date;
    amount: number;
    success: boolean;
}

Summary: Inheritance as Specialization

We've established the right mental model for inheritance: specialization. Here's the complete framework:

Key Takeaways

•Think specialization, not reuse — Children are specialized versions of parents, not just code recipients.
•Apply the strong IS-A test — Every child must substitute for the parent in ALL contexts, not just some.
•Behavioral contracts matter — Specialization preserves or strengthens contracts, never breaks them.
•Extend, don't restrict — Children add capabilities; they don't remove or disable parent capabilities.
•Model domain concepts — Hierarchies should reflect genuine domain categories and specializations.
•Recognize red flags — Unused methods, role-based types, and deep hierarchies signal design problems.
•Follow design principles — Abstract parents, shallow hierarchies, documented contracts, and favor composition when in doubt.
•Test with substitution — If you can't use the child wherever you'd use the parent, the hierarchy is wrong.

Module complete!

You now have a comprehensive understanding of what inheritance is:

Its precise definition and mechanics
How parent and child classes relate
What gets inherited and how
The conceptual model (specialization) that should guide your use

The next module explores the IS-A relationship in greater depth, examining when inheritance is truly appropriate and how to test for valid inheritance relationships.

Module Complete

You've mastered the fundamentals of inheritance: definition, parent-child relationships, member inheritance, and the specialization mindset. You can now recognize when inheritance is appropriate, design sound hierarchies, and avoid common pitfalls that lead to fragile or incorrect object-oriented designs.

4 / 4

Loading learning content...

System Design (HLD)What Is Inheritance?

What Is Inheritance?

LevelBeginner

Duration55 mins

TopicWhat Is Inheritance?

4 / 4

Inheritance as Specialization

The Right Mental Model

This page establishes specialization as the guiding principle for inheritance and explores how to apply it correctly.

What You Will Learn

What is Specialization?

Specialization is the process of creating a more specific version of something while preserving its essential nature. A specialized entity:

Is still fundamentally what the general type is — A SportsCar is still a Car
Has all the characteristics of the general type — SportsCars have wheels, engines, steering
Adds additional, more specific characteristics — SportsCars have turbos, spoilers, better handling
May refine general behavior — SportsCars accelerate faster, but still accelerate

The hierarchy of concepts:

Specialization creates natural hierarchies in the real world and in software:

Vehicle (most general)
├── Car (more specific)
│   ├── SportsCar (even more specific)
│   │   └── Ferrari458 (very specific)
│   └── FamilyCar
├── Motorcycle
└── Truck

Each level adds specificity. Each child is a valid member of every ancestor category. A Ferrari458 is a SportsCar, is a Car, is a Vehicle.

The Specialization Test

The IS-A Relationship: Formalized

The IS-A test is the standard way to evaluate whether inheritance is appropriate. But the test is often applied too casually. Let's formalize it.

Strong IS-A (appropriate for inheritance):

An X IS-A Y if and only if:

Every instance of X can substitute for any instance of Y in any context

The substitution makes semantic sense in the domain

The relationship is permanent and unconditional

Weak IS-A (inappropriate for inheritance):

An X seems like a Y might apply when:

X shares some behavior with Y

X could be described using Y in some contexts

The relationship depends on interpretation or perspective

Strong IS-A vs. Weak IS-A Examples
Relationship	IS-A Type	Reasoning	Verdict
Dog IS-A Animal	Strong	Every dog is always an animal, in every context	✅ Inherit
Cat IS-A Pet	Weak	Not all cats are pets (wild cats). Context-dependent	❌ Avoid
Rectangle IS-A Shape	Strong	Every rectangle is always a shape	✅ Inherit
Square IS-A Rectangle	Weak*	Mathematically yes, but mutability creates issues (see LSP)	⚠️ Careful
Manager IS-A Employee	Strong	Every manager is always an employee	✅ Inherit
Customer IS-A Person	Weak	A customer is a role, not a permanent identity	❌ Avoid
SavingsAccount IS-A BankAccount	Strong	Every savings account is always a bank account	✅ Inherit
Stack IS-A ArrayList	Weak	Stack uses array-like storage, but isn't an array conceptually	❌ Avoid

The Square-Rectangle Problem

Behavioral Specialization: More Than Data

True specialization involves behavioral compatibility, not just structural similarity. The child must honor the behavioral contract established by the parent.

What behavioral specialization means:

Behavioral Specialization Requirements

•Preconditions preserved or weakened — If parent's method requires positive numbers, child can accept any number (weaker) but not require only even numbers (stronger)
•Postconditions preserved or strengthened — If parent promises non-null return, child must also return non-null (can promise more, like 'always returns positive')
•Invariants preserved — If parent's balance is always non-negative, child must maintain this
•Exceptions compatible — Child can throw fewer or more specific exceptions, not new unrelated ones
•Side effects compatible — If parent doesn't modify global state, child shouldn't either

behavioral-specialization
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
67
68
69
70
71
// Parent establishes behavioral contracts
class Sorter {
    /**
     * Sorts the array in ascending order.
     * @param arr - The array to sort (will not be modified)
     * @returns A new sorted array
     * 
     * Contract:
     * - Precondition: arr is not null
     * - Postcondition: Returns non-null array with same elements, in ascending order
     * - Invariant: Original array is unchanged
     */
    public sort(arr: number[]): number[] {
        return [...arr].sort((a, b) => a - b);
    }
}
 
// GOOD specialization: honors all contracts
class StableSorter extends Sorter {
    /**
     * Sorts using a stable algorithm (equal elements stay in original order).
     * Strengthens postcondition: guaranteed stable sort.
     */
    public sort(arr: number[]): number[] {
        // Stable merge sort - satisfies parent's contract + adds guarantee
        return this.mergeSort([...arr]);
    }
    
    private mergeSort(arr: number[]): number[] {
        if (arr.length <= 1) return arr;
        const mid = Math.floor(arr.length / 2);
        const left = this.mergeSort(arr.slice(0, mid));
        const right = this.mergeSort(arr.slice(mid));
        return this.merge(left, right);
    }
    
    private merge(left: number[], right: number[]): number[] {
        const result: number[] = [];
        let l = 0, r = 0;
        while (l < left.length && r < right.length) {
            if (left[l] <= right[r]) result.push(left[l++]);
            else result.push(right[r++]);
        }
        return result.concat(left.slice(l), right.slice(r));
    }
}
 
// BAD specialization: violates contracts
class BrokenSorter extends Sorter {
    /**
     * PROBLEM: Modifies input array (violates invariant)
     * PROBLEM: Returns null for empty arrays (violates postcondition)
     */
    public sort(arr: number[]): number[] {
        if (arr.length === 0) return null!;  // ❌ Violates postcondition
        arr.sort((a, b) => a - b);            // ❌ Violates invariant
        return arr;
    }
}
 
// Usage showing why contracts matter
function processScores(sorter: Sorter, scores: number[]): void {
    const original = [...scores];
    const sorted = sorter.sort(scores);
    
    // These assertions should ALWAYS pass if sorter follows the contract
    console.assert(scores.join() === original.join(), "Original unchanged");
    console.assert(sorted !== null, "Never returns null");
    
    // BrokenSorter would fail both assertions!
}

Extension vs. Restriction: What Children Can Do

Specialization typically means extending the parent's capabilities, not restricting them. This is a crucial principle often violated.

Extension (appropriate):

The child adds new capabilities while preserving all parent capabilities.

Car extends Vehicle → adds doors, trunk
EmailNotification extends Notification → adds subject line
SportsPlayer extends Person → adds team, position, stats

Restriction (problematic):

The child removes or disables parent capabilities.

Penguin extends Bird → removes flying ability
ImmutableList extends List → adds but add/remove throw exceptions
DisabledButton extends Button → click does nothing

Extension (Good Specialization)

•Child can do everything parent can
•Child adds NEW methods
•Child refines or enhances parent methods
•Substitution works seamlessly
•No surprises for callers

Restriction (Bad Specialization)

•Child throws exceptions for valid parent operations
•Child silently ignores parent method calls
•Child has methods that 'don't apply'
•Substitution causes runtime errors
•Violates caller expectations

restriction-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
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
// The Classic "Penguin Problem"
 
class Bird {
    protected name: string;
    
    constructor(name: string) {
        this.name = name;
    }
    
    public fly(): void {
        console.log(`${this.name} is flying through the air!`);
    }
    
    public eat(): void {
        console.log(`${this.name} is eating.`);
    }
}
 
// ❌ BAD: Penguin restricts Bird's capabilities
class Penguin extends Bird {
    public fly(): void {
        // What do we do here?
        
        // Option 1: Throw exception (violates substitution)
        throw new Error("Penguins can't fly!");
        
        // Option 2: Do nothing (violates expected behavior)
        // console.log("Nothing happens...");  
        
        // Option 3: Waddle instead (changes semantics)
        // console.log(`${this.name} waddles on the ground`);
    }
}
 
// This is legal but leads to runtime problems
function migrateBirds(birds: Bird[]): void {
    for (const bird of birds) {
        bird.fly();  // Will crash for Penguins!
    }
}
 
// ✅ BETTER: Restructure the hierarchy
abstract class Bird2 {
    protected name: string;
    
    constructor(name: string) {
        this.name = name;
    }
    
    public abstract move(): void;  // All birds move somehow
    public eat(): void {
        console.log(`${this.name} is eating.`);
    }
}
 
class FlyingBird extends Bird2 {
    public move(): void {
        console.log(`${this.name} flies through the air`);
    }
    
    public fly(): void {
        this.move();  // Alias for clarity
    }
}
 
class FlightlessBird extends Bird2 {
    public move(): void {
        console.log(`${this.name} walks on the ground`);
    }
}
 
class Eagle extends FlyingBird {
    public soar(): void {
        console.log(`${this.name} soars on thermal currents`);
    }
}
 
class Penguin2 extends FlightlessBird {
    public swim(): void {
        console.log(`${this.name} swims gracefully`);
    }
}

The Restructuring Principle

Specialization in Domain Modeling

The best inheritance hierarchies model genuine domain concepts. They reflect how experts in the domain actually think about categories and specializations.

Domain-driven hierarchy design:

Listen to domain experts — How do they describe categories? What words do they use?
Look for 'kind of' language — 'An X is a kind of Y' often indicates true specialization
Test with substitution — Can domain experts use a child wherever they'd use a parent?
Watch for roles vs. types — A 'Customer' is a role a Person plays, not a specialization of Person

domain-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
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
// Example: Financial Instruments Domain
 
// Domain concept: All financial instruments share these characteristics
abstract class FinancialInstrument {
    protected readonly symbol: string;
    protected readonly issuedDate: Date;
    
    constructor(symbol: string, issuedDate: Date) {
        this.symbol = symbol;
        this.issuedDate = issuedDate;
    }
    
    public abstract getCurrentValue(): number;
    public abstract getDescription(): string;
}
 
// Specialization: Equity instruments (ownership stakes)
abstract class Equity extends FinancialInstrument {
    protected sharesOutstanding: number;
    
    constructor(symbol: string, issuedDate: Date, sharesOutstanding: number) {
        super(symbol, issuedDate);
        this.sharesOutstanding = sharesOutstanding;
    }
    
    public abstract getDividendYield(): number;
}
 
// Further specialization
class CommonStock extends Equity {
    private pricePerShare: number;
    private annualDividend: number;
    
    constructor(
        symbol: string, 
        issuedDate: Date, 
        sharesOutstanding: number,
        pricePerShare: number,
        annualDividend: number
    ) {
        super(symbol, issuedDate, sharesOutstanding);
        this.pricePerShare = pricePerShare;
        this.annualDividend = annualDividend;
    }
    
    public getCurrentValue(): number {
        return this.pricePerShare * this.sharesOutstanding;
    }
    
    public getDividendYield(): number {
        return this.annualDividend / this.pricePerShare;
    }
    
    public getDescription(): string {
        return `Common Stock: ${this.symbol}`;
    }
}
 
class PreferredStock extends Equity {
    private parValue: number;
    private fixedDividendRate: number;
    
    constructor(
        symbol: string,
        issuedDate: Date,
        sharesOutstanding: number,
        parValue: number,
        fixedDividendRate: number
    ) {
        super(symbol, issuedDate, sharesOutstanding);
        this.parValue = parValue;
        this.fixedDividendRate = fixedDividendRate;
    }
    
    public getCurrentValue(): number {
        return this.parValue * this.sharesOutstanding;
    }
    
    public getDividendYield(): number {
        return this.fixedDividendRate;  // Fixed rate, not calculated
    }
    
    public getDescription(): string {
        return `Preferred Stock: ${this.symbol} (${this.fixedDividendRate * 100}%)`;
    }
}
 
// Different branch of specialization: Debt instruments
abstract class Debt extends FinancialInstrument {
    protected principalAmount: number;
    protected interestRate: number;
    protected maturityDate: Date;
    
    constructor(
        symbol: string,
        issuedDate: Date,
        principalAmount: number,
        interestRate: number,
        maturityDate: Date
    ) {
        super(symbol, issuedDate);
        this.principalAmount = principalAmount;
        this.interestRate = interestRate;
        this.maturityDate = maturityDate;
    }
    
    public abstract getInterestPayment(): number;
}
 
class CorporateBond extends Debt {
    private creditRating: string;
    
    constructor(
        symbol: string,
        issuedDate: Date,
        principalAmount: number,
        interestRate: number,
        maturityDate: Date,
        creditRating: string
    ) {
        super(symbol, issuedDate, principalAmount, interestRate, maturityDate);
        this.creditRating = creditRating;
    }
    
    public getCurrentValue(): number {
        // Bond valuation based on rates, simplified here
        return this.principalAmount;
    }
    
    public getInterestPayment(): number {
        return this.principalAmount * this.interestRate;
    }
    
    public getDescription(): string {
        return `Corporate Bond: ${this.symbol} (Rating: ${this.creditRating})`;
    }
}
 
// Usage: Work with financial instruments polymorphically
function calculatePortfolioValue(instruments: FinancialInstrument[]): number {
    return instruments.reduce((sum, inst) => sum + inst.getCurrentValue(), 0);
}

Recognizing Bad Hierarchies

Experience teaches us to recognize inheritance relationships that will cause problems. Here are the warning signs:

Red Flags in Inheritance Design

•'Unused methods' smell — Child inherits methods it doesn't need or makes no sense to call. Example: 'Immutable list has add() method that throws.'
•'Role-based hierarchy' smell — Modeling roles as types. 'Customer extends Person' breaks when one person can be both customer and employee.
•'Convenience inheritance' smell — Child extends parent primarily for code reuse without genuine IS-A relationship.
•'Parallel hierarchies' smell — When one hierarchy exists primarily to mirror another: Shape/ShapeFactory, Document/DocumentRenderer.
•'God parent' smell — Parent class is too broad, too generic, or has too many children with unrelated characteristics.
•'Deep hierarchy' smell — Many levels of inheritance; changes at top ripple unpredictably; hard to understand where behavior comes from.
•'Override everything' smell — Children override almost all parent methods, indicating the parent's behavior doesn't really fit.

The Alternative: Composition

Design Principles for Specialization

Applying specialization correctly requires deliberate design. Here are actionable principles:

Specialization Design Principles

•Design parents for extension — Think about who will extend and how. Provide protected hooks. Document what's safe to override.
•Keep hierarchies shallow — Prefer 1-2 levels of inheritance. Deeper hierarchies are harder to understand and more fragile.
•Favor abstract parents — If a class is extended, it often shouldn't be instantiated directly. Make it abstract.
•Test substitutability — For each child, verify it works correctly in every context where parent is expected.
•Match domain concepts — The hierarchy should reflect domain reality, not implementation convenience.
•Use interfaces for capabilities — If you need 'mixin' behavior or horizontal categorization, use interfaces or composition.
•Document behavioral contracts — Make explicit what children must preserve when overriding.
•Prefer composition for code reuse — If the relationship isn't truly IS-A, use HAS-A instead.

good-hierarchy-example
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
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
/**
 * Example: Well-designed hierarchy following all principles
 */
 
// Abstract parent - designed for extension
abstract class PaymentProcessor {
    protected transactionLog: TransactionEntry[] = [];
    
    // Template method - defines the algorithm, not meant to be overridden
    public async processPayment(amount: number, details: PaymentDetails): Promise<PaymentResult> {
        // Validation (can be customized)
        const validation = await this.validatePayment(amount, details);
        if (!validation.valid) {
            return { success: false, error: validation.reason };
        }
        
        // Core processing (must be implemented)
        const result = await this.executePayment(amount, details);
        
        // Logging (can be customized)
        this.logTransaction(amount, details, result);
        
        return result;
    }
    
    // Override hook: customize validation
    protected async validatePayment(
        amount: number, 
        details: PaymentDetails
    ): Promise<ValidationResult> {
        // Default validation
        if (amount <= 0) {
            return { valid: false, reason: "Invalid amount" };
        }
        return { valid: true };
    }
    
    // Must be implemented by children
    protected abstract executePayment(
        amount: number, 
        details: PaymentDetails
    ): Promise<PaymentResult>;
    
    // Override hook: customize logging
    protected logTransaction(
        amount: number, 
        details: PaymentDetails, 
        result: PaymentResult
    ): void {
        this.transactionLog.push({
            timestamp: new Date(),
            amount,
            success: result.success,
        });
    }
}
 
// First specialization level
class CardPaymentProcessor extends PaymentProcessor {
    protected async executePayment(
        amount: number, 
        details: PaymentDetails
    ): Promise<PaymentResult> {
        // Card-specific implementation
        const cardDetails = details as CardPaymentDetails;
        // ... process card payment
        return { success: true, transactionId: "card_" + Date.now() };
    }
    
    protected async validatePayment(
        amount: number, 
        details: PaymentDetails
    ): Promise<ValidationResult> {
        // Card-specific validation + parent validation
        const baseResult = await super.validatePayment(amount, details);
        if (!baseResult.valid) return baseResult;
        
        const cardDetails = details as CardPaymentDetails;
        if (!this.isValidCardNumber(cardDetails.cardNumber)) {
            return { valid: false, reason: "Invalid card number" };
        }
        return { valid: true };
    }
    
    private isValidCardNumber(cardNumber: string): boolean {
        // Luhn algorithm check
        return cardNumber.length >= 13;
    }
}
 
// Capability via interface, not inheritance
interface RefundCapable {
    processRefund(transactionId: string, amount: number): Promise<PaymentResult>;
}
 
// Second specialization level (shallow hierarchy)
class RefundableCardProcessor extends CardPaymentProcessor implements RefundCapable {
    async processRefund(transactionId: string, amount: number): Promise<PaymentResult> {
        // Refund-specific logic
        return { success: true, transactionId: "refund_" + Date.now() };
    }
}
 
// Types used above
interface PaymentDetails {
    type: string;
}
 
interface CardPaymentDetails extends PaymentDetails {
    cardNumber: string;
    expiryDate: string;
    cvv: string;
}
 
interface PaymentResult {
    success: boolean;
    transactionId?: string;
    error?: string;
}
 
interface ValidationResult {
    valid: boolean;
    reason?: string;
}
 
interface TransactionEntry {
    timestamp: Date;
    amount: number;
    success: boolean;
}

Summary: Inheritance as Specialization

We've established the right mental model for inheritance: specialization. Here's the complete framework:

Key Takeaways

•Think specialization, not reuse — Children are specialized versions of parents, not just code recipients.
•Apply the strong IS-A test — Every child must substitute for the parent in ALL contexts, not just some.
•Behavioral contracts matter — Specialization preserves or strengthens contracts, never breaks them.
•Extend, don't restrict — Children add capabilities; they don't remove or disable parent capabilities.
•Model domain concepts — Hierarchies should reflect genuine domain categories and specializations.
•Recognize red flags — Unused methods, role-based types, and deep hierarchies signal design problems.
•Follow design principles — Abstract parents, shallow hierarchies, documented contracts, and favor composition when in doubt.
•Test with substitution — If you can't use the child wherever you'd use the parent, the hierarchy is wrong.

Module complete!

You now have a comprehensive understanding of what inheritance is:

Its precise definition and mechanics
How parent and child classes relate
What gets inherited and how
The conceptual model (specialization) that should guide your use

The next module explores the IS-A relationship in greater depth, examining when inheritance is truly appropriate and how to test for valid inheritance relationships.

Module Complete

4 / 4