System Design (HLD)What Is Inheritance?

What Is Inheritance?

LevelBeginner

Duration55 mins

TopicWhat Is Inheritance?

1 / 4

Definition of Inheritance

The Promise of Reuse

Every experienced software engineer has faced this moment: you're designing a new class, and you realize it shares significant functionality with a class you've already written. Perhaps you're building a SavingsAccount class and notice it needs most of the same attributes and methods as your existing BankAccount class. Or you're creating a ElectricCar class and recognize it should behave like your Car class with some additional features.

The naive solution—copying and pasting code—creates a maintenance nightmare. Change the original, and you must remember to update every copy. Miss one, and you've introduced subtle bugs that may not surface for months.

Inheritance is object-oriented programming's elegant solution to this fundamental problem. It allows one class to acquire the properties and behaviors of another, establishing a hierarchical relationship that promotes code reuse while maintaining a single source of truth.

What You Will Learn

By the end of this page, you will understand exactly what inheritance is, why it exists, and how it fundamentally changes the way we think about organizing code. You'll grasp the precise mechanics of how one class 'inherits' from another and understand the foundational vocabulary that every object-oriented developer must command.

The Formal Definition

Inheritance is a mechanism in object-oriented programming whereby a new class (called the derived class, subclass, or child class) is created from an existing class (called the base class, superclass, or parent class) by incorporating all of the parent's attributes and methods, with the ability to add new ones or modify inherited behaviors.

Let's dissect this definition precisely:

Key Elements of the Definition

•Mechanism — Inheritance is a language-level feature, not a design pattern. It's built into the syntax and semantics of object-oriented languages. When you use inheritance, the compiler or runtime enforces specific rules about how classes relate.
•New class from existing class — Inheritance creates a relationship between two classes. The parent class must exist before the child can extend it. This establishes a temporal and logical dependency.
•Incorporating attributes and methods — The child class automatically gains access to the parent's non-private members. This is not copying—it's sharing. The child has all the capabilities of the parent without duplicating code.
•Ability to add or modify — Inheritance isn't just about receiving; it's about extending and customizing. The child can add new attributes, add new methods, or override inherited methods to change behavior.

The Essence of Inheritance

At its core, inheritance answers this question: 'How can I create a new type that is like an existing type, but different in specific ways?' The answer is to inherit what stays the same and override or extend what differs.

The mathematical perspective:

From a type theory standpoint, inheritance establishes a subtype relationship. If class B inherits from class A, then every instance of B is also an instance of A. In set-theoretic terms, the set of all B objects is a subset of the set of all A objects.

This has profound implications:

Anywhere an A is expected, a B can be provided
Any operation valid on an A is valid on a B
A B has at least the capabilities of an A, possibly more

This is the foundation of polymorphism, which we'll explore in detail in later chapters. For now, understand that inheritance creates a type hierarchy where child types are compatible with parent types.

The Problem Inheritance Solves

To truly understand inheritance, we must understand the problems that existed before it—the problems that drove language designers to create this mechanism.

The Copy-Paste Anti-Pattern:

Before inheritance, if you wanted two classes to share behavior, you had limited options:

Copy-paste the code — Duplicate the shared attributes and methods in each class
Use utility functions — Extract shared logic into standalone functions that each class calls
Composition only — Have each class contain an instance of a shared helper class

Each approach has significant drawbacks:

Pre-Inheritance Approaches and Their Drawbacks
Approach	Implementation	Drawbacks
Copy-Paste	Duplicate code in each class	Maintenance nightmare; bugs must be fixed in multiple places; no guarantee of consistency
Utility Functions	Standalone functions that operate on data	Breaks encapsulation; data and behavior separated; procedural rather than object-oriented
Composition Only	Classes contain helper objects	Doesn't establish 'is-a' relationships; can't substitute one type for another; verbose delegation

A concrete example of the problem:

Imagine you're building a system that models different types of employees. You have:

Employee — with attributes like name, id, salary and methods like calculatePay(), getDetails()
Manager — an employee who also has directReports and methods like assignTask(), conductReview()
Engineer — an employee who also has programmingLanguages and methods like writeCode(), reviewCode()

Without inheritance, you'd have to:

Copy all the Employee attributes and methods into both Manager and Engineer, OR
Have Manager and Engineer each contain an Employee object and delegate every call

Both approaches are unsatisfying. The first creates code duplication. The second doesn't let you treat managers and engineers as employees—you can't put them in an Employee[] array or pass them to functions expecting an Employee.

The Real Value of Inheritance

Inheritance solves two problems simultaneously: (1) code reuse without duplication, and (2) type compatibility between related classes. You get both the shared implementation AND the ability to treat derived types as their base type. This dual benefit is why inheritance became a pillar of OOP.

Historical Context: The Origins of Inheritance

Understanding where inheritance came from illuminates why it works the way it does.

Simula 67: The Birthplace of Inheritance

Inheritance as a programming concept was first introduced in Simula 67, developed by Ole-Johan Dahl and Kristen Nygaard at the Norwegian Computing Center. Simula was designed for simulation modeling—representing real-world entities and their behaviors in code.

The designers noticed that simulations often involve entities that share characteristics. A simulation of a harbor might have Ship, CargoShip, and PassengerShip. All ships share certain properties (size, speed, position), but specialized ships have additional attributes and behaviors.

Rather than forcing programmers to duplicate the common 'ship' logic, Dahl and Nygaard introduced the concept of a class hierarchy. A class could be declared as a subclass of another, automatically incorporating the parent's definition.

Smalltalk: Inheritance Matures

Alan Kay's Smalltalk (developed at Xerox PARC in the 1970s) refined inheritance into the form we recognize today. Smalltalk introduced:

Single-rooted hierarchy (all classes ultimately inherit from Object)
Message passing as the primary interaction mechanism
Dynamic method dispatch (runtime determination of which method to call)

C++ and Java: Industry Adoption

Bjarne Stroustrup's C++ (1980s) brought inheritance to systems programming, while James Gosling's Java (1990s) made it mainstream for enterprise development. Both languages refined the syntax and semantics, introducing concepts like access modifiers for inheritance, abstract classes, and interface inheritance.

Why History Matters

Inheritance was designed for modeling real-world hierarchies—simulation domains where 'kinds of things' naturally existed. When you use inheritance, you're most effective when your domain actually has these hierarchical IS-A relationships. Using inheritance for pure code reuse (without genuine type relationships) often leads to design problems.

The Mechanics of Inheritance

Let's examine precisely what happens when one class inherits from another. Understanding the mechanics helps you reason about behavior and avoid common pitfalls.

What the child class receives:

Inherited from Parent

•Public attributes — All attributes declared as public in the parent are accessible in the child with the same visibility
•Protected attributes — Attributes visible to the class and its subclasses become available to the child
•Public methods — All public methods can be called on child instances exactly as on parent instances
•Protected methods — Methods intended for the class hierarchy become available to the child
•The parent's type identity — The child IS-A parent, enabling polymorphic behavior

NOT Inherited (or Not Directly Accessible)

•Private attributes — These exist in the parent portion of the object but cannot be directly accessed by child code
•Private methods — Internal implementation details of the parent remain encapsulated
•Constructors — Constructors are not inherited; the child must define its own (though it can call the parent's)
•Static members (in some languages) — Static members belong to the class itself, not the hierarchy

Memory layout perspective:

When you create an instance of a child class, the object in memory contains:

All the attributes defined by the parent class (including private ones)
All the attributes defined by the child class

The child object is literally a 'superset' of the parent object. This is why a child can be used wherever a parent is expected—it has everything the parent has, plus potentially more.

Method resolution:

When you call a method on a child object:

The runtime first checks if the child class defines or overrides that method
If not, it checks the parent class
This continues up the hierarchy until the method is found
If no class in the hierarchy defines the method, you get a compile error (or runtime error in dynamic languages)

This mechanism—called method dispatch or virtual method table lookup—is what enables polymorphism. The same method call can execute different code depending on the actual type of the object.

inheritance-mechanics
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
// Parent class (base class, superclass)
class Animal {
    // Public attribute - inherited and accessible
    public name: string;
    
    // Protected attribute - inherited, accessible only in hierarchy
    protected age: number;
    
    // Private attribute - NOT accessible in child (but exists in memory)
    private internalId: string;
    
    constructor(name: string, age: number) {
        this.name = name;
        this.age = age;
        this.internalId = `animal_${Date.now()}`;
    }
    
    // Public method - inherited and callable
    public speak(): string {
        return `${this.name} makes a sound`;
    }
    
    // Protected method - available to children
    protected getAgeInMonths(): number {
        return this.age * 12;
    }
    
    // Private method - NOT accessible in child
    private generateId(): string {
        return `id_${Math.random()}`;
    }
}
 
// Child class (derived class, subclass)
class Dog extends Animal {
    // Child adds its own attribute
    public breed: string;
    
    constructor(name: string, age: number, breed: string) {
        // Must call parent constructor first
        super(name, age);
        this.breed = breed;
    }
    
    // Child overrides parent method
    public speak(): string {
        return `${this.name} barks!`;  // ✅ Can access inherited 'name'
    }
    
    // Child adds its own method
    public fetch(): string {
        const months = this.getAgeInMonths();  // ✅ Can access protected method
        return `${this.name} (${months} months old) fetches the ball!`;
    }
    
    // This would NOT compile:
    // private showId(): string {
    //     return this.internalId;  // ❌ Cannot access private parent member
    // }
}
 
// Usage demonstrating inheritance mechanics
const myDog = new Dog("Max", 3, "Golden Retriever");
 
console.log(myDog.name);       // ✅ "Max" - public inherited
console.log(myDog.breed);      // ✅ "Golden Retriever" - child's own
console.log(myDog.speak());    // ✅ "Max barks!" - overridden method
console.log(myDog.fetch());    // ✅ Calls child method using protected parent method
 
// Type compatibility - Dog IS-A Animal
const animal: Animal = myDog;  // ✅ Valid - child can be assigned to parent type
console.log(animal.speak());   // ✅ "Max barks!" - polymorphism in action

Mastering the Terminology

Object-oriented programming uses multiple terms for the same concepts. Fluency requires knowing all variants and their nuances.

Inheritance Terminology Across Contexts
Concept	Terms Used	Context Notes
The class being extended	Parent class, Base class, Superclass	"Parent" emphasizes hierarchy; "Base" emphasizes foundation; "Super" is Java/Kotlin convention
The class that extends	Child class, Derived class, Subclass	"Child" emphasizes hierarchy; "Derived" emphasizes creation from another; "Sub" is Java convention
The act of extending	Inherits from, Extends, Derives from	"Extends" is the Java/TypeScript keyword; "Derives" is common in C++/C# discussion
The relationship type	IS-A relationship, Subtype relationship	"IS-A" is design terminology; "Subtype" is type theory terminology
Creating a child object	Instantiation of a derived type	The child is still instantiated normally; inheritance affects what's in the instance
Changing inherited behavior	Overriding, Redefining	"Override" is standard; some older texts use "redefine"
Calling parent's version	super.method(), base.method()	"super" in Java/TypeScript/Python; "base" in C#

Terminology Consistency

In this curriculum, we'll use 'parent/child' for intuitive discussion and 'superclass/subclass' when being technical. Both are correct—use what your team uses, but understand all variants.

Important distinctions:

Inheritance vs. Implementation:

Inheritance typically refers to extending a class (getting both interface and implementation)
Implementation (as in "implementing an interface") means providing method bodies for an abstract contract

Inheritance vs. Subtyping:

Inheritance is the mechanism (code sharing)
Subtyping is the type relationship (substitutability)
In most OOP languages, inheritance implies subtyping, but they're conceptually distinct

extends vs. implements:

extends creates an inheritance relationship with a class
implements creates a contractual relationship with an interface
A class can extend one class (in most languages) but implement multiple interfaces

Types of Inheritance

Not all inheritance is the same. Understanding the different forms helps you recognize what your language supports and what patterns are possible.

Inheritance Classifications

•Single Inheritance — A class can have only one direct parent. This is the model in Java, C#, and most modern languages. It creates a simple tree hierarchy. Example: Dog extends Animal — Dog has exactly one parent.
•Multiple Inheritance — A class can have multiple direct parents, inheriting from all of them. This is supported in C++ and Python. It creates a directed acyclic graph (DAG) structure. Example: FlyingFish extends Fish, Bird — FlyingFish inherits from two parents. This introduces the 'diamond problem' we'll discuss in later modules.
•Multilevel Inheritance — A chain of inheritance: grandparent → parent → child. All single-inheritance languages support this. Example: Animal → Mammal → Dog — Dog inherits from Mammal, which inherits from Animal.
•Hierarchical Inheritance — Multiple classes inherit from a single parent. Example: Animal is extended by both Dog and Cat. This creates a fan-out structure.
•Interface Inheritance — Inheriting only the contract (method signatures) without implementation. Java interfaces and TypeScript interfaces work this way. A class can inherit from multiple interfaces even in single-inheritance languages.

Visual representation of inheritance types:

Converting Mermaid diagram...

Multiple Inheritance Complexity

Multiple inheritance (where a class has more than one parent class) introduces significant complexity, including the 'diamond problem' where the same method might be inherited through multiple paths. Most modern languages (Java, C#, TypeScript) intentionally avoid multiple inheritance of classes, allowing only multiple inheritance of interfaces.

When Inheritance Applies

Inheritance is a powerful tool, but it's not always the right tool. Understanding when inheritance genuinely applies—and when it's being misused—is crucial for good design.

The litmus test: IS-A relationship

Inheritance should model a genuine IS-A relationship:

A Dog IS-A Animal ✅
A SavingsAccount IS-A BankAccount ✅
A Circle IS-A Shape ✅

If you can't naturally say "X is a Y" where Y is the parent and X is the child, inheritance may be inappropriate:

A Car IS-A Engine? ❌ (A car HAS-A engine)
A Stack IS-A ArrayList? ❌ (A stack uses an ArrayList internally, HAS-A)
A Logger IS-A FileWriter? ❌ (A logger may use a FileWriter, HAS-A)

Good Uses of Inheritance

•Modeling genuine type hierarchies from the domain
•Specializing behavior while maintaining type compatibility
•Creating abstract types with shared implementation
•Enabling polymorphism through substitutability
•Establishing framework extension points

Misuses of Inheritance

•Reusing code without genuine IS-A relationship
•Inheriting from utility classes for convenience
•Creating deep hierarchies for maximum reuse
•Using inheritance when composition suffices
•Forcing hierarchies where they don't exist

The Golden Rule

Use inheritance for TYPE RELATIONSHIPS, not for code reuse. If you're inheriting just to get some useful methods, consider composition instead. If X truly IS-A Y in your domain, inheritance is appropriate. If X merely USES functionality similar to Y, prefer composition.

Inheritance vs. Other Mechanisms

Inheritance is one of several mechanisms for code reuse and abstraction. Understanding how it compares helps you choose the right tool.

Inheritance Compared to Other Mechanisms
Mechanism	What It Provides	Relationship Type	When to Use
Inheritance	Type hierarchy + shared implementation	IS-A (subtype)	When child truly is a specialized version of parent
Composition	Objects containing other objects	HAS-A (containment)	When object uses another object's functionality
Aggregation	Objects referencing other objects (weak ownership)	HAS-A (association)	When object logically contains but doesn't control lifetime
Interfaces	Contract without implementation	CAN-DO (capability)	When defining capabilities without dictating implementation
Mixins/Traits	Reusable behavior units	ACTS-LIKE (behavior inclusion)	When multiple unrelated classes need same behavior

The famous principle: Favor Composition Over Inheritance

This principle, popularized by the Gang of Four in Design Patterns, recognizes that inheritance creates tight coupling. When you inherit:

You're locked into the parent's interface
Changes to the parent ripple to all children
You can only inherit from one class (in most languages)
The relationship is static—decided at compile time

Composition, by contrast:

Allows runtime flexibility (swap implementations)
Creates looser coupling
Enables combining multiple behaviors
Keeps each component independently testable

This doesn't mean inheritance is bad—it means it should be used deliberately, for genuine type hierarchies, not as a default code-sharing mechanism.

Summary: The Definition of Inheritance

We've established a comprehensive understanding of what inheritance is. Let's consolidate the key points:

Key Takeaways

•Inheritance is a language mechanism that allows a child class to acquire the attributes and methods of a parent class, establishing a type hierarchy.
•Child classes inherit public and protected members but cannot directly access private members. Constructors are not inherited.
•Inheritance establishes an IS-A relationship — the child type is a subtype of the parent, meaning children can substitute for parents.
•Historical context grounds us: inheritance was designed for modeling real-world hierarchies in simulation, where IS-A relationships genuinely exist.
•Multiple forms exist: single, multiple, multilevel, and hierarchical inheritance, plus interface inheritance. Most modern languages use single class inheritance with multiple interface inheritance.
•Inheritance should model genuine type relationships, not just facilitate code reuse. The IS-A test helps determine appropriateness.
•Inheritance complements other mechanisms like composition, interfaces, and mixins. Each has its place; none is universally superior.

What's next:

Now that we understand what inheritance is in abstract terms, the next page explores the parent/child relationship in depth. We'll examine how superclasses and subclasses interact, the mechanics of constructor chaining, and the semantics of the 'extends' relationship that binds parent and child classes together.

Page Complete

You now have a precise, comprehensive definition of inheritance. You understand its purpose, mechanics, historical context, and appropriate use cases. This foundation will support everything else you learn about inheritance and object-oriented hierarchies.

1 / 4

Loading learning content...

Definition of Inheritance - What Is Inheritance? | OneNoughtOne

System Design (HLD)What Is Inheritance?

What Is Inheritance?

LevelBeginner

Duration55 mins

TopicWhat Is Inheritance?

1 / 4

Definition of Inheritance

The Promise of Reuse

What You Will Learn

The Formal Definition

Let's dissect this definition precisely:

Key Elements of the Definition

•Mechanism — Inheritance is a language-level feature, not a design pattern. It's built into the syntax and semantics of object-oriented languages. When you use inheritance, the compiler or runtime enforces specific rules about how classes relate.
•New class from existing class — Inheritance creates a relationship between two classes. The parent class must exist before the child can extend it. This establishes a temporal and logical dependency.
•Incorporating attributes and methods — The child class automatically gains access to the parent's non-private members. This is not copying—it's sharing. The child has all the capabilities of the parent without duplicating code.
•Ability to add or modify — Inheritance isn't just about receiving; it's about extending and customizing. The child can add new attributes, add new methods, or override inherited methods to change behavior.

The Essence of Inheritance

The mathematical perspective:

This has profound implications:

Anywhere an A is expected, a B can be provided
Any operation valid on an A is valid on a B
A B has at least the capabilities of an A, possibly more

The Problem Inheritance Solves

To truly understand inheritance, we must understand the problems that existed before it—the problems that drove language designers to create this mechanism.

The Copy-Paste Anti-Pattern:

Before inheritance, if you wanted two classes to share behavior, you had limited options:

Copy-paste the code — Duplicate the shared attributes and methods in each class
Use utility functions — Extract shared logic into standalone functions that each class calls
Composition only — Have each class contain an instance of a shared helper class

Each approach has significant drawbacks:

Pre-Inheritance Approaches and Their Drawbacks
Approach	Implementation	Drawbacks
Copy-Paste	Duplicate code in each class	Maintenance nightmare; bugs must be fixed in multiple places; no guarantee of consistency
Utility Functions	Standalone functions that operate on data	Breaks encapsulation; data and behavior separated; procedural rather than object-oriented
Composition Only	Classes contain helper objects	Doesn't establish 'is-a' relationships; can't substitute one type for another; verbose delegation

A concrete example of the problem:

Imagine you're building a system that models different types of employees. You have:

Employee — with attributes like name, id, salary and methods like calculatePay(), getDetails()
Manager — an employee who also has directReports and methods like assignTask(), conductReview()
Engineer — an employee who also has programmingLanguages and methods like writeCode(), reviewCode()

Without inheritance, you'd have to:

Copy all the Employee attributes and methods into both Manager and Engineer, OR
Have Manager and Engineer each contain an Employee object and delegate every call

The Real Value of Inheritance

Historical Context: The Origins of Inheritance

Understanding where inheritance came from illuminates why it works the way it does.

Simula 67: The Birthplace of Inheritance

Smalltalk: Inheritance Matures

Alan Kay's Smalltalk (developed at Xerox PARC in the 1970s) refined inheritance into the form we recognize today. Smalltalk introduced:

Single-rooted hierarchy (all classes ultimately inherit from Object)
Message passing as the primary interaction mechanism
Dynamic method dispatch (runtime determination of which method to call)

C++ and Java: Industry Adoption

Why History Matters

The Mechanics of Inheritance

Let's examine precisely what happens when one class inherits from another. Understanding the mechanics helps you reason about behavior and avoid common pitfalls.

What the child class receives:

Inherited from Parent

•Public attributes — All attributes declared as public in the parent are accessible in the child with the same visibility
•Protected attributes — Attributes visible to the class and its subclasses become available to the child
•Public methods — All public methods can be called on child instances exactly as on parent instances
•Protected methods — Methods intended for the class hierarchy become available to the child
•The parent's type identity — The child IS-A parent, enabling polymorphic behavior

NOT Inherited (or Not Directly Accessible)

•Private attributes — These exist in the parent portion of the object but cannot be directly accessed by child code
•Private methods — Internal implementation details of the parent remain encapsulated
•Constructors — Constructors are not inherited; the child must define its own (though it can call the parent's)
•Static members (in some languages) — Static members belong to the class itself, not the hierarchy

Memory layout perspective:

When you create an instance of a child class, the object in memory contains:

All the attributes defined by the parent class (including private ones)
All the attributes defined by the child class

The child object is literally a 'superset' of the parent object. This is why a child can be used wherever a parent is expected—it has everything the parent has, plus potentially more.

Method resolution:

When you call a method on a child object:

The runtime first checks if the child class defines or overrides that method
If not, it checks the parent class
This continues up the hierarchy until the method is found
If no class in the hierarchy defines the method, you get a compile error (or runtime error in dynamic languages)

inheritance-mechanics
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
// Parent class (base class, superclass)
class Animal {
    // Public attribute - inherited and accessible
    public name: string;
    
    // Protected attribute - inherited, accessible only in hierarchy
    protected age: number;
    
    // Private attribute - NOT accessible in child (but exists in memory)
    private internalId: string;
    
    constructor(name: string, age: number) {
        this.name = name;
        this.age = age;
        this.internalId = `animal_${Date.now()}`;
    }
    
    // Public method - inherited and callable
    public speak(): string {
        return `${this.name} makes a sound`;
    }
    
    // Protected method - available to children
    protected getAgeInMonths(): number {
        return this.age * 12;
    }
    
    // Private method - NOT accessible in child
    private generateId(): string {
        return `id_${Math.random()}`;
    }
}
 
// Child class (derived class, subclass)
class Dog extends Animal {
    // Child adds its own attribute
    public breed: string;
    
    constructor(name: string, age: number, breed: string) {
        // Must call parent constructor first
        super(name, age);
        this.breed = breed;
    }
    
    // Child overrides parent method
    public speak(): string {
        return `${this.name} barks!`;  // ✅ Can access inherited 'name'
    }
    
    // Child adds its own method
    public fetch(): string {
        const months = this.getAgeInMonths();  // ✅ Can access protected method
        return `${this.name} (${months} months old) fetches the ball!`;
    }
    
    // This would NOT compile:
    // private showId(): string {
    //     return this.internalId;  // ❌ Cannot access private parent member
    // }
}
 
// Usage demonstrating inheritance mechanics
const myDog = new Dog("Max", 3, "Golden Retriever");
 
console.log(myDog.name);       // ✅ "Max" - public inherited
console.log(myDog.breed);      // ✅ "Golden Retriever" - child's own
console.log(myDog.speak());    // ✅ "Max barks!" - overridden method
console.log(myDog.fetch());    // ✅ Calls child method using protected parent method
 
// Type compatibility - Dog IS-A Animal
const animal: Animal = myDog;  // ✅ Valid - child can be assigned to parent type
console.log(animal.speak());   // ✅ "Max barks!" - polymorphism in action

Mastering the Terminology

Object-oriented programming uses multiple terms for the same concepts. Fluency requires knowing all variants and their nuances.

Inheritance Terminology Across Contexts
Concept	Terms Used	Context Notes
The class being extended	Parent class, Base class, Superclass	"Parent" emphasizes hierarchy; "Base" emphasizes foundation; "Super" is Java/Kotlin convention
The class that extends	Child class, Derived class, Subclass	"Child" emphasizes hierarchy; "Derived" emphasizes creation from another; "Sub" is Java convention
The act of extending	Inherits from, Extends, Derives from	"Extends" is the Java/TypeScript keyword; "Derives" is common in C++/C# discussion
The relationship type	IS-A relationship, Subtype relationship	"IS-A" is design terminology; "Subtype" is type theory terminology
Creating a child object	Instantiation of a derived type	The child is still instantiated normally; inheritance affects what's in the instance
Changing inherited behavior	Overriding, Redefining	"Override" is standard; some older texts use "redefine"
Calling parent's version	super.method(), base.method()	"super" in Java/TypeScript/Python; "base" in C#

Terminology Consistency

In this curriculum, we'll use 'parent/child' for intuitive discussion and 'superclass/subclass' when being technical. Both are correct—use what your team uses, but understand all variants.

Important distinctions:

Inheritance vs. Implementation:

Inheritance typically refers to extending a class (getting both interface and implementation)
Implementation (as in "implementing an interface") means providing method bodies for an abstract contract

Inheritance vs. Subtyping:

Inheritance is the mechanism (code sharing)
Subtyping is the type relationship (substitutability)
In most OOP languages, inheritance implies subtyping, but they're conceptually distinct

extends vs. implements:

extends creates an inheritance relationship with a class
implements creates a contractual relationship with an interface
A class can extend one class (in most languages) but implement multiple interfaces

Types of Inheritance

Not all inheritance is the same. Understanding the different forms helps you recognize what your language supports and what patterns are possible.

Inheritance Classifications

•Single Inheritance — A class can have only one direct parent. This is the model in Java, C#, and most modern languages. It creates a simple tree hierarchy. Example: Dog extends Animal — Dog has exactly one parent.
•Multiple Inheritance — A class can have multiple direct parents, inheriting from all of them. This is supported in C++ and Python. It creates a directed acyclic graph (DAG) structure. Example: FlyingFish extends Fish, Bird — FlyingFish inherits from two parents. This introduces the 'diamond problem' we'll discuss in later modules.
•Multilevel Inheritance — A chain of inheritance: grandparent → parent → child. All single-inheritance languages support this. Example: Animal → Mammal → Dog — Dog inherits from Mammal, which inherits from Animal.
•Hierarchical Inheritance — Multiple classes inherit from a single parent. Example: Animal is extended by both Dog and Cat. This creates a fan-out structure.
•Interface Inheritance — Inheriting only the contract (method signatures) without implementation. Java interfaces and TypeScript interfaces work this way. A class can inherit from multiple interfaces even in single-inheritance languages.

Visual representation of inheritance types:

Converting Mermaid diagram...

Multiple Inheritance Complexity

When Inheritance Applies

Inheritance is a powerful tool, but it's not always the right tool. Understanding when inheritance genuinely applies—and when it's being misused—is crucial for good design.

The litmus test: IS-A relationship

Inheritance should model a genuine IS-A relationship:

A Dog IS-A Animal ✅
A SavingsAccount IS-A BankAccount ✅
A Circle IS-A Shape ✅

If you can't naturally say "X is a Y" where Y is the parent and X is the child, inheritance may be inappropriate:

A Car IS-A Engine? ❌ (A car HAS-A engine)
A Stack IS-A ArrayList? ❌ (A stack uses an ArrayList internally, HAS-A)
A Logger IS-A FileWriter? ❌ (A logger may use a FileWriter, HAS-A)

Good Uses of Inheritance

•Modeling genuine type hierarchies from the domain
•Specializing behavior while maintaining type compatibility
•Creating abstract types with shared implementation
•Enabling polymorphism through substitutability
•Establishing framework extension points

Misuses of Inheritance

•Reusing code without genuine IS-A relationship
•Inheriting from utility classes for convenience
•Creating deep hierarchies for maximum reuse
•Using inheritance when composition suffices
•Forcing hierarchies where they don't exist

The Golden Rule

Inheritance vs. Other Mechanisms

Inheritance is one of several mechanisms for code reuse and abstraction. Understanding how it compares helps you choose the right tool.

Inheritance Compared to Other Mechanisms
Mechanism	What It Provides	Relationship Type	When to Use
Inheritance	Type hierarchy + shared implementation	IS-A (subtype)	When child truly is a specialized version of parent
Composition	Objects containing other objects	HAS-A (containment)	When object uses another object's functionality
Aggregation	Objects referencing other objects (weak ownership)	HAS-A (association)	When object logically contains but doesn't control lifetime
Interfaces	Contract without implementation	CAN-DO (capability)	When defining capabilities without dictating implementation
Mixins/Traits	Reusable behavior units	ACTS-LIKE (behavior inclusion)	When multiple unrelated classes need same behavior

The famous principle: Favor Composition Over Inheritance

This principle, popularized by the Gang of Four in Design Patterns, recognizes that inheritance creates tight coupling. When you inherit:

You're locked into the parent's interface
Changes to the parent ripple to all children
You can only inherit from one class (in most languages)
The relationship is static—decided at compile time

Composition, by contrast:

Allows runtime flexibility (swap implementations)
Creates looser coupling
Enables combining multiple behaviors
Keeps each component independently testable

This doesn't mean inheritance is bad—it means it should be used deliberately, for genuine type hierarchies, not as a default code-sharing mechanism.

Summary: The Definition of Inheritance

We've established a comprehensive understanding of what inheritance is. Let's consolidate the key points:

Key Takeaways

•Inheritance is a language mechanism that allows a child class to acquire the attributes and methods of a parent class, establishing a type hierarchy.
•Child classes inherit public and protected members but cannot directly access private members. Constructors are not inherited.
•Inheritance establishes an IS-A relationship — the child type is a subtype of the parent, meaning children can substitute for parents.
•Historical context grounds us: inheritance was designed for modeling real-world hierarchies in simulation, where IS-A relationships genuinely exist.
•Multiple forms exist: single, multiple, multilevel, and hierarchical inheritance, plus interface inheritance. Most modern languages use single class inheritance with multiple interface inheritance.
•Inheritance should model genuine type relationships, not just facilitate code reuse. The IS-A test helps determine appropriateness.
•Inheritance complements other mechanisms like composition, interfaces, and mixins. Each has its place; none is universally superior.

What's next:

Page Complete

1 / 4