System Design (LLD)The IS-A Relationship

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

LevelIntermediate

Duration50 mins

TopicThe IS-A Relationship

1 / 4

When Inheritance Is Appropriate

The Seductive Trap of Inheritance

Inheritance is one of the most powerful mechanisms in object-oriented programming—and one of the most misused. Every experienced engineer has encountered codebases where inheritance hierarchies have spiraled into unmaintainable tangled webs, where changing a single method in a base class cascades into dozens of unexpected breaks across subclasses.

The seduction is understandable. On the surface, inheritance appears to offer the holy grail of software engineering: write code once, reuse it everywhere. Need a Manager class? Just extend Employee and add a few methods. Need a AdminUser? Extend User. The code compiles, tests pass, and you move on.

But months later, you're staring at a class hierarchy that nobody wants to touch. Every change requires understanding ten classes. Every new requirement forces awkward workarounds. The inheritance that promised simplicity has delivered complexity.

What You Will Learn

By the end of this page, you will understand the fundamental criteria for when inheritance is genuinely appropriate. You'll learn to distinguish between inheritance that creates elegant, maintainable hierarchies and inheritance that leads to design debt. This knowledge will save you countless hours of refactoring and prevent the creation of rigid, brittle class structures.

The True Purpose of Inheritance

Before we can determine when to use inheritance, we must understand why it exists. Inheritance serves two fundamentally different purposes, and conflating them is the source of most inheritance misuse:

Purpose 1: Modeling Taxonomic Relationships

In the real world, things naturally form hierarchies. A Sparrow is a Bird. A Bird is an Animal. A Square is a Rectangle. These relationships aren't arbitrary—they reflect genuine categorical membership where the child is a specialized type of the parent.

Purpose 2: Code Reuse

Inheritance also allows child classes to automatically receive the implementation of parent classes. Write a method once in the parent, and all children inherit it. This is tremendously convenient—and tremendously dangerous when used as the primary motivation for inheritance.

The Critical Distinction

Inheritance for code reuse without a genuine IS-A relationship is the single most common cause of inheritance abuse. Just because two classes share some behavior does not mean one should inherit from the other. The relationship must be semantically meaningful, not just syntactically convenient.

The litmus test:

When evaluating whether class B should extend class A, ask yourself:

"In every conceivable context, in every possible scenario within the problem domain, can I truthfully say that B is an A?"

If the answer is "yes, but only sometimes" or "yes, but with exceptions," inheritance is likely the wrong tool. True inheritance relationships hold universally, not conditionally.

Behavioral Substitutability: The Golden Rule

The most rigorous test for appropriate inheritance comes from behavioral substitutability, formalized as the Liskov Substitution Principle (which we'll explore in detail later). The core idea is simple yet profound:

If class Child extends class Parent, then anywhere in your code that expects a Parent object, you must be able to use a Child object without breaking the program's correctness.

This isn't just about compilation or even about tests passing. It's about semantic correctness. The program must behave as expected when any child is substituted for its parent.

substitutability_example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// Consider a function that operates on Shape
function calculateTotalArea(shapes: Shape[]): number {
    let total = 0;
    for (const shape of shapes) {
        total += shape.getArea();
    }
    return total;
}
 
// This function should work correctly with ANY Shape subclass
const shapes: Shape[] = [
    new Circle(5),
    new Rectangle(4, 3),
    new Triangle(3, 4, 5),
    new Square(6)
];
 
// If Square is truly a Shape, this must work correctly
// If Square's getArea() behaves differently than expected,
// we have a substitutability violation
const area = calculateTotalArea(shapes);

Why substitutability matters:

When code depends on a parent type, it makes assumptions about behavior. If children violate those assumptions, the code breaks—often in subtle, hard-to-debug ways. Consider what happens if Square is substituted where Rectangle is expected, but Square doesn't allow independent width/height modification. Code that relies on modifying dimensions independently will fail mysteriously.

Substitutability ensures that inheritance creates reliable abstractions. Without it, inheritance becomes a source of hidden bugs rather than a tool for clean design.

Contract Preservation: Maintaining Promises

Every class makes implicit or explicit contracts with its users—promises about what its methods will do. Inheritance is appropriate only when children can honor all of the parent's contracts.

A contract includes:

Preconditions: What must be true before a method is called
Postconditions: What will be true after a method completes
Invariants: What is always true about the object's state

Contract Rules for Proper Inheritance
Contract Type	Rule for Child Classes	Violation Example
Preconditions	May be equal or weaker (accept more)	Parent accepts positive numbers; child requires positive AND even
Postconditions	May be equal or stronger (guarantee more)	Parent guarantees sorted output; child returns unsorted
Invariants	Must be preserved (never violated)	Parent maintains balance ≥ 0; child allows negative balance

The intuition behind these rules:

Weakening preconditions means the child is more accepting than the parent. Code that could call the parent's method can definitely call the child's.
Strengthening postconditions means the child guarantees more than the parent. Code that relied on the parent's guarantees gets even stronger guarantees from the child.
Preserving invariants means the child maintains the same fundamental truths about state that the parent does.

If these rules are violated, substituting a child for its parent will break expectations—the definition of inappropriate inheritance.

Practical Application

When designing a subclass, explicitly list the contracts of the parent class. For each method you override, ask: "Am I maintaining or strengthening these contracts, or am I weakening them?" If you find yourself needing to weaken contracts, reconsider whether inheritance is the right relationship.

Extension, Not Restriction

A fundamental principle for appropriate inheritance is that child classes should extend capabilities, not restrict them. The child may add new methods, specialize behavior, or introduce new attributes—but it should never take away capabilities that the parent provided.

This principle has a name in object-oriented design: the open-closed principle's corollary for inheritance. If a parent can do X, every child must be able to do X too.

Appropriate: Extension

•Adding new methods
•Adding new attributes
•Specializing existing behavior (same contract)
•Providing more efficient implementations
•Handling more input cases

Inappropriate: Restriction

•Throwing exceptions for inherited methods
•Making inherited methods no-ops
•Changing method behavior incompatibly
•Rejecting inputs the parent accepts
•Removing functionality via override

restriction_violation
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
// VIOLATION: Child restricts parent behavior
class Bird {
    fly(): void {
        console.log("Flying through the air!");
    }
    
    eat(): void {
        console.log("Eating food");
    }
}
 
class Penguin extends Bird {
    // ❌ VIOLATION: Restricting inherited capability
    fly(): void {
        throw new Error("Penguins cannot fly!");
    }
    
    // This forces every caller to handle an exception
    // that the parent's contract never promised
    swim(): void {
        console.log("Swimming gracefully");
    }
}
 
// Code written against Bird will break with Penguin
function migrateBirds(birds: Bird[]): void {
    for (const bird of birds) {
        bird.fly(); // 💥 Throws for Penguin!
    }
}

The Penguin Problem is a classic example of inappropriate inheritance. While it's true that a penguin is a bird biologically, in a software model where Bird has a fly() method, Penguin cannot be a proper subclass. The solution isn't to make fly() throw an exception—it's to redesign the hierarchy.

Possible solutions:

Create separate FlyingBird and FlightlessBird classes
Use composition: birds have a MovementStrategy rather than being flying or not
Define Bird without fly(), and add it in FlyingBird subclass

The right solution depends on the domain, but the essential insight is: if you need to restrict capabilities, inheritance is wrong.

Semantic Coherence Across the Domain

Appropriate inheritance must be semantically coherent within the problem domain. This means the IS-A relationship must hold not just syntactically (the code compiles) or behaviorally (tests pass), but meaningfully in the context of what the software models.

Domain-first thinking:

Before creating an inheritance relationship, step back and think about the domain:

Would a domain expert recognize this relationship as valid?
Does the terminology make sense? (e.g., "A PremiumAccount is an Account")
Will this relationship remain true as the domain evolves?
Are there edge cases in the domain where the relationship breaks down?

Questions to Validate Semantic Coherence

•Is the relationship permanent? — A Student might become a Teacher, but a Circle can never become a Square. Prefer inheritance for immutable type distinctions.
•Is the relationship universal? — Is it true in all contexts of your application, or only in some? Partial relationships suggest composition instead.
•Does the vocabulary align? — If you'd never say "X is a kind of Y" when talking about your domain, don't model them with inheritance.
•Is the hierarchy stable? — Will new requirements force you to reorganize? Frequent restructuring indicates design problems.
•Do experts agree? — Domain experts, architects, and developers should all nod when they see the hierarchy.

The Real-World Test

If you drew your class hierarchy on a whiteboard and explained it to a domain expert (a banker for banking software, a doctor for medical software, etc.), would they agree with the relationships? If they'd say "Well, technically..." or "That's not quite right," your hierarchy likely needs revision.

Stability Analysis: Will It Last?

One of the most important considerations for appropriate inheritance is stability. Inheritance creates a tight coupling between parent and child. Changes to the parent ripple down to all children. This means you should only create inheritance relationships when:

The parent class is stable — Its interface and behavior are unlikely to change
The relationship is enduring — It will remain valid as requirements evolve
The hierarchy depth is limited — Deep hierarchies amplify coupling problems

Stability Indicators for Inheritance Decisions
Indicator	Suggests Inheritance	Suggests Composition
Parent class maturity	Well-established, battle-tested	Newly created, still evolving
Change frequency	Rarely changes	Frequently modified
Domain concept clarity	Clear, precise meaning	Fuzzy, debated interpretation
Cross-team usage	Used by many teams	Single-team internal use
Standardization	Industry-standard concept	Application-specific concept

The stability principle in practice:

Framework designers and library authors understand this deeply. Look at mature object-oriented frameworks:

Standard library classes like Exception, Object, or Number are designed to be extended because they represent stable, well-understood abstractions.
Business domain classes should be extended cautiously because business requirements change constantly.
Configuration and preference classes almost never warrant inheritance—they should use composition.

Ask yourself: "If the parent class changes, how many places in my codebase will need to adapt?" If the answer is "many," ensure the parent is genuinely stable before committing to inheritance.

The Library Author's Perspective

Imagine you're publishing your class as a library that thousands of developers will use. Would you be comfortable if they all created subclasses? If the thought makes you nervous because you might need to change the class, that's a signal that inheritance might not be appropriate.

A Practical Decision Framework

Synthesizing everything we've discussed, here is a practical decision framework for determining when inheritance is appropriate:

Inheritance Appropriateness Checklist

•IS-A Test — Can you sincerely say "Child IS-A Parent" in all contexts? Not "acts like" or "can be used as"—but genuinely is.
•Substitutability — Can every child instance replace its parent without breaking any code that depends on the parent?
•Contract Preservation — Does the child honor all preconditions, postconditions, and invariants of the parent?
•Extension Only — Does the child extend capabilities rather than restrict them? No throwing "not supported" exceptions?
•Semantic Coherence — Would domain experts agree with the relationship? Does the vocabulary make sense?
•Stability — Is the parent class stable and unlikely to change? Is the relationship enduring?
•Shallow Hierarchy — Will this create a hierarchy of 2-3 levels, not 5-10?

If any answer is "no" or "uncertain," strongly consider composition instead.

Composition (HAS-A relationships) provides many of inheritance's benefits with far less coupling and greater flexibility. The next pages will contrast IS-A properly with common mistakes that lead developers astray.

Page Complete

You now understand the fundamental criteria for when inheritance is appropriate. Inheritance is powerful when used for genuine IS-A relationships that preserve contracts, extend (not restrict) behavior, and create stable, semantically coherent hierarchies. In the next page, we'll formalize the IS-A test and give you concrete tools for applying it to real design decisions.

1 / 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

1 / 4

When Inheritance Is Appropriate

The Seductive Trap of Inheritance

What You Will Learn

The True Purpose of Inheritance

Purpose 1: Modeling Taxonomic Relationships

Purpose 2: Code Reuse

The Critical Distinction

The litmus test:

When evaluating whether class B should extend class A, ask yourself:

"In every conceivable context, in every possible scenario within the problem domain, can I truthfully say that B is an A?"

If the answer is "yes, but only sometimes" or "yes, but with exceptions," inheritance is likely the wrong tool. True inheritance relationships hold universally, not conditionally.

Behavioral Substitutability: The Golden Rule

If class Child extends class Parent, then anywhere in your code that expects a Parent object, you must be able to use a Child object without breaking the program's correctness.

This isn't just about compilation or even about tests passing. It's about semantic correctness. The program must behave as expected when any child is substituted for its parent.

substitutability_example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// Consider a function that operates on Shape
function calculateTotalArea(shapes: Shape[]): number {
    let total = 0;
    for (const shape of shapes) {
        total += shape.getArea();
    }
    return total;
}
 
// This function should work correctly with ANY Shape subclass
const shapes: Shape[] = [
    new Circle(5),
    new Rectangle(4, 3),
    new Triangle(3, 4, 5),
    new Square(6)
];
 
// If Square is truly a Shape, this must work correctly
// If Square's getArea() behaves differently than expected,
// we have a substitutability violation
const area = calculateTotalArea(shapes);

Why substitutability matters:

Substitutability ensures that inheritance creates reliable abstractions. Without it, inheritance becomes a source of hidden bugs rather than a tool for clean design.

Contract Preservation: Maintaining Promises

Every class makes implicit or explicit contracts with its users—promises about what its methods will do. Inheritance is appropriate only when children can honor all of the parent's contracts.

A contract includes:

Preconditions: What must be true before a method is called
Postconditions: What will be true after a method completes
Invariants: What is always true about the object's state

Contract Rules for Proper Inheritance
Contract Type	Rule for Child Classes	Violation Example
Preconditions	May be equal or weaker (accept more)	Parent accepts positive numbers; child requires positive AND even
Postconditions	May be equal or stronger (guarantee more)	Parent guarantees sorted output; child returns unsorted
Invariants	Must be preserved (never violated)	Parent maintains balance ≥ 0; child allows negative balance

The intuition behind these rules:

Weakening preconditions means the child is more accepting than the parent. Code that could call the parent's method can definitely call the child's.
Strengthening postconditions means the child guarantees more than the parent. Code that relied on the parent's guarantees gets even stronger guarantees from the child.
Preserving invariants means the child maintains the same fundamental truths about state that the parent does.

If these rules are violated, substituting a child for its parent will break expectations—the definition of inappropriate inheritance.

Practical Application

Extension, Not Restriction

This principle has a name in object-oriented design: the open-closed principle's corollary for inheritance. If a parent can do X, every child must be able to do X too.

Appropriate: Extension

•Adding new methods
•Adding new attributes
•Specializing existing behavior (same contract)
•Providing more efficient implementations
•Handling more input cases

Inappropriate: Restriction

•Throwing exceptions for inherited methods
•Making inherited methods no-ops
•Changing method behavior incompatibly
•Rejecting inputs the parent accepts
•Removing functionality via override

restriction_violation
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
// VIOLATION: Child restricts parent behavior
class Bird {
    fly(): void {
        console.log("Flying through the air!");
    }
    
    eat(): void {
        console.log("Eating food");
    }
}
 
class Penguin extends Bird {
    // ❌ VIOLATION: Restricting inherited capability
    fly(): void {
        throw new Error("Penguins cannot fly!");
    }
    
    // This forces every caller to handle an exception
    // that the parent's contract never promised
    swim(): void {
        console.log("Swimming gracefully");
    }
}
 
// Code written against Bird will break with Penguin
function migrateBirds(birds: Bird[]): void {
    for (const bird of birds) {
        bird.fly(); // 💥 Throws for Penguin!
    }
}

Possible solutions:

Create separate FlyingBird and FlightlessBird classes
Use composition: birds have a MovementStrategy rather than being flying or not
Define Bird without fly(), and add it in FlyingBird subclass

The right solution depends on the domain, but the essential insight is: if you need to restrict capabilities, inheritance is wrong.

Semantic Coherence Across the Domain

Domain-first thinking:

Before creating an inheritance relationship, step back and think about the domain:

Would a domain expert recognize this relationship as valid?
Does the terminology make sense? (e.g., "A PremiumAccount is an Account")
Will this relationship remain true as the domain evolves?
Are there edge cases in the domain where the relationship breaks down?

Questions to Validate Semantic Coherence

•Is the relationship permanent? — A Student might become a Teacher, but a Circle can never become a Square. Prefer inheritance for immutable type distinctions.
•Is the relationship universal? — Is it true in all contexts of your application, or only in some? Partial relationships suggest composition instead.
•Does the vocabulary align? — If you'd never say "X is a kind of Y" when talking about your domain, don't model them with inheritance.
•Is the hierarchy stable? — Will new requirements force you to reorganize? Frequent restructuring indicates design problems.
•Do experts agree? — Domain experts, architects, and developers should all nod when they see the hierarchy.

The Real-World Test

Stability Analysis: Will It Last?

The parent class is stable — Its interface and behavior are unlikely to change
The relationship is enduring — It will remain valid as requirements evolve
The hierarchy depth is limited — Deep hierarchies amplify coupling problems

Stability Indicators for Inheritance Decisions
Indicator	Suggests Inheritance	Suggests Composition
Parent class maturity	Well-established, battle-tested	Newly created, still evolving
Change frequency	Rarely changes	Frequently modified
Domain concept clarity	Clear, precise meaning	Fuzzy, debated interpretation
Cross-team usage	Used by many teams	Single-team internal use
Standardization	Industry-standard concept	Application-specific concept

The stability principle in practice:

Framework designers and library authors understand this deeply. Look at mature object-oriented frameworks:

Standard library classes like Exception, Object, or Number are designed to be extended because they represent stable, well-understood abstractions.
Business domain classes should be extended cautiously because business requirements change constantly.
Configuration and preference classes almost never warrant inheritance—they should use composition.

Ask yourself: "If the parent class changes, how many places in my codebase will need to adapt?" If the answer is "many," ensure the parent is genuinely stable before committing to inheritance.

The Library Author's Perspective

A Practical Decision Framework

Synthesizing everything we've discussed, here is a practical decision framework for determining when inheritance is appropriate:

Inheritance Appropriateness Checklist

•IS-A Test — Can you sincerely say "Child IS-A Parent" in all contexts? Not "acts like" or "can be used as"—but genuinely is.
•Substitutability — Can every child instance replace its parent without breaking any code that depends on the parent?
•Contract Preservation — Does the child honor all preconditions, postconditions, and invariants of the parent?
•Extension Only — Does the child extend capabilities rather than restrict them? No throwing "not supported" exceptions?
•Semantic Coherence — Would domain experts agree with the relationship? Does the vocabulary make sense?
•Stability — Is the parent class stable and unlikely to change? Is the relationship enduring?
•Shallow Hierarchy — Will this create a hierarchy of 2-3 levels, not 5-10?

If any answer is "no" or "uncertain," strongly consider composition instead.

Page Complete

1 / 4