The Java Inheritance Chronicles: A Narrative Guide to Building on the Shoulders of Code

Introduction: The Art of the Blueprint

Imagine a master architect commissioned to design a new skyscraper.

This architect does not start by reinventing the fundamental concept of a “building.” They do not re-calculate the physics of load-bearing walls or redesign plumbing systems from scratch.

Instead, they begin with a foundational blueprint—a master plan that defines what it means to be a structure, with core systems for electricity, water, and support.

From this general blueprint, they create specialized designs: a residential tower with apartments and balconies, an office complex with open-plan floors and data centers, or a hospital with specialized wards and operating theaters.

Each new design inherits the essential qualities of the master blueprint but adds unique features to serve its specific purpose.

Object-Oriented Programming (OOP), the paradigm that underpins modern Java, operates on this same powerful principle of reuse and specialization.¹

The mechanism that makes this possible is

inheritance.

It allows a new class, our specialized blueprint, to be based on an existing one, automatically acquiring its common characteristics (known as fields or state) and behaviors (known as methods).³

This fundamental concept is a cornerstone of OOP because it promotes code reusability, saving developers from the tedious and error-prone task of writing the same logic repeatedly.⁴

To explore this concept in its full depth, this report will embark on a narrative journey: the creation of a virtual “Vehicle Factory.” Our mission is to design and build a diverse range of vehicles, from a basic family car to a high-performance sports car.

This practical, story-driven approach will serve as our guide through the intricate and powerful world of Java inheritance, revealing not only how it works but, more importantly, why it is designed the way it is and when it should be used.

Chapter 1: The Primordial Design – The Vehicle Superclass

The Foundation

Every great manufacturing enterprise begins with a foundational design.

In our Vehicle Factory, this is the Vehicle class.

This class will serve as our superclass—a term used interchangeably with parent class or base class—representing the most general form of any vehicle we intend to build.³

It will define the state and behavior that are common to every vehicle, from a delivery truck to a motorcycle.

Let’s lay this cornerstone with our first piece of code:

Java

// File: Vehicle.java
public class Vehicle {
    // Fields (state) common to all vehicles
    protected String make;
    protected String model;
    protected int year;
    private int speed;

    // Constructor to initialize the object’s state
    public Vehicle(String make, String model, int year) {
        this.make = make;
        this.model = model;
        this.year = year;
        this.speed = 0; // All vehicles start stationary
    }

    // Methods (behavior) common to all vehicles
    public void accelerate(int increment) {
        this.speed += increment;
        System.O.T.println(“Accelerating.

Current speed: ” + this.speed + ” mph.”);
    }

    public void brake(int decrement) {
        if (this.speed – decrement >= 0) {
            this.speed -= decrement;
        } else {
            this.speed = 0;
        }
        System.O.T.println(“Braking.

Current speed: ” + this.speed + ” mph.”);
    }

    public void displayInfo() {
        System.O.T.println(“Vehicle: ” + this.year + ” ” + this.make + ” ” + this.model);
    }

    public int getSpeed() {
        return this.speed;
    }
}

Analysis of the Blueprint

This Vehicle class acts as our template.

It establishes that every vehicle in our system will have a make, model, year, and a speed.

It also defines universal behaviors: accelerate, brake, and displayInfo.

A key design choice here is the use of access modifiers.

The fields make, model, and year are declared as protected.

This modifier signifies that these members are accessible not only within the Vehicle class itself but also by any future child classes (subclasses) that inherit from it, regardless of which package they reside in.⁶

In contrast, the

speed field is private, meaning it can only be accessed and modified directly within the Vehicle class itself.

This enforces encapsulation, a core OOP principle, by ensuring that the speed can only be changed through the controlled accelerate and brake methods.

The Universal Ancestor

In the world of Java, no class is truly an island.

While our Vehicle class does not explicitly state that it inherits from anything, it is, in fact, already part of a grand hierarchy.

Every class in Java that does not have an extends clause in its declaration implicitly inherits from the java.lang.Object class.⁶

This makes

Object the ultimate ancestor, the primordial superclass at the very top of Java’s entire class hierarchy.⁶

This design is not accidental; it is a deliberate and powerful feature of the language.

The Java designers needed a way to provide universal functionality to every single object.

Rather than forcing every developer to implement common behaviors, they placed them in the Object class, ensuring they are automatically available to all.

These inherited methods include some of the most fundamental operations in Java:

• toString(): Returns a string representation of the object.
• equals(Object obj): Compares the object to another for equality.
• hashCode(): Returns a hash code value for the object, used in hash-based collections like HashMap.
• getClass(): Returns the runtime class of the object.

This means our Vehicle class, from the moment of its creation, already stands on the shoulders of Object.

It has inherited these essential methods, which are often excellent candidates for being customized in subclasses—a concept known as overriding that will be explored later.⁸

This establishes the hierarchical nature of the Java class system from the very beginning.

Chapter 2: The First Specialization – Forging a Car with extends and super

With our foundational Vehicle blueprint in place, we can now create our first specialized product: a Car.

A car is fundamentally a type of vehicle, but it has additional, specific attributes, such as the number of doors.

In OOP, we model this relationship by creating a subclass (also called a child class or derived class) that inherits from our Vehicle superclass.³

The extends Keyword: Establishing the “Is-A” Relationship

The core mechanism for creating a subclass in Java is the extends keyword.

This keyword is placed in the class declaration and formally establishes the inheritance relationship.²

It signifies what is known as an

“is-a” relationship: by declaring class Car extends Vehicle, we are telling the Java compiler that a Car is a specialized type of Vehicle.¹¹

Let’s draft the initial structure of our Car class:

Java

// File: Car.java
public class Car extends Vehicle {
    // Field specific to Car
    private int numberOfDoors;

    // Constructor for the Car class
    public Car(String make, String model, int year, int numberOfDoors) {
        // How do we initialize the inherited fields ‘make’, ‘model’, ‘year’ from Vehicle?
        // This is where ‘super’ comes in.
    }
}

Because Car extends Vehicle, it automatically inherits all the public and protected fields and methods from Vehicle.

A Car object will have a make, model, and year, and it can be made to accelerate() and brake() without us writing a single line of code for those features in the Car class itself.⁶

The super Keyword: A Call to the Parent

A critical question arises in the constructor: how do we initialize the fields that belong to the Vehicle part of our Car object? A fundamental rule in Java is that constructors are not inherited.⁷

A subclass does not automatically get the constructors of its superclass.

The

Car class is responsible for its own construction process, which must include the proper initialization of the state it inherits from Vehicle.

The solution is the super keyword.

When used as a method call, super() invokes a constructor from the immediate superclass.⁶

This call must be the absolute

first line in the subclass’s constructor.¹⁴

This ensures that the “parent” part of the object is fully constructed before the subclass adds its own specific initializations.

Here is the complete and correct constructor for our Car class:

Java

// Inside the Car class
public Car(String make, String model, int year, int numberOfDoors) {
    // Call the superclass (Vehicle) constructor to initialize inherited fields.
    // This must be the first statement.
    super(make, model, year);
   
    // Now, initialize the field specific to the Car class.
    this.numberOfDoors = numberOfDoors;
}

In this code, super(make, model, year) is a direct call to the public Vehicle(String make, String model, int year) constructor in the Vehicle class.

It passes the relevant arguments “up” to the parent for initialization.

After the superclass constructor completes, the Car constructor then proceeds to initialize its own specific field, numberOfDoors.

It is important to note that if a subclass constructor does not explicitly call a superclass constructor with super(), the Java compiler will automatically insert a call to the superclass’s no-argument constructor, super(), as the first line.¹⁴

If the superclass does not have a no-argument constructor, this will result in a compile-time error.

This forces the programmer to be deliberate about the chain of construction.

super() as an Encapsulation Enforcer

The rule that super() must be the first statement in a constructor is not merely a syntactic quirk; it is a powerful mechanism that respects and enforces the principle of encapsulation.

The superclass, Vehicle, is the sole authority on its own state.

Its fields, especially private ones like speed, should only be initialized and manipulated through its own defined interface—its constructors and methods.

If a subclass like Car were allowed to directly access and initialize the private state of its parent, it would create a tight, brittle dependency on the parent’s internal implementation details.¹⁵

This would violate encapsulation.

The

super() call elegantly solves this by delegating the responsibility of initializing the “parent part” of the object back to the parent itself.

The Car constructor effectively says, “I don’t need to know how you set up the make, model, and year.

That’s your job.

Just do it with these values I’m providing.”

This enforces a clean separation of concerns.

The superclass retains full control over its own state and initialization logic, making the overall system more robust and maintainable.

The subclass can then focus exclusively on what makes it unique.

Chapter 3: A Custom Engine Note – Method Overriding and the Dawn of Polymorphism

Our Car class now correctly inherits the state and behavior of a Vehicle.

However, a Car is a more specific entity, and we might want to customize some of its inherited behavior.

For instance, the displayInfo() method from Vehicle is useful, but it doesn’t tell us anything about the car’s unique properties, like its number of doors.

To add this specific detail, we use a technique called method overriding.¹

Method overriding allows a subclass to provide its own specific implementation for an instance method that is already defined in its superclass.¹⁸

When this method is called on an object of the subclass, the subclass’s version is executed instead of the superclass’s version.

The @Override Annotation and the super Dot Operator

To override a method, we simply declare a method in the subclass with the exact same signature (name and parameters) as the method in the superclass.¹⁶

While not strictly required, it is a strongly recommended best practice to precede the method declaration with the

@Override annotation.¹¹

This annotation serves as an instruction to the compiler, signaling our intent to override a superclass method.

If we make a mistake, such as misspelling the method name or using the wrong parameter types, the compiler will generate an error, preventing subtle runtime bugs that can be difficult to diagnose.¹³

Often, we don’t want to completely replace the superclass’s behavior but rather augment it.

We can achieve this by using the super keyword followed by a dot (.) to explicitly call the overridden method from the parent class.¹³

Let’s enhance our Car class by overriding displayInfo():

Java

// Inside the Car class
@Override
public void displayInfo() {
    // First, call the superclass’s version of the method to print the common info.
    super.displayInfo();
   
    // Then, add the car-specific information.
    System.out.println(“Number of Doors: ” + this.numberOfDoors);
}

With this change, calling displayInfo() on a Car object will first execute the displayInfo() logic from Vehicle (printing the make, model, and year) and then execute the new logic from Car (printing the number of doors).

The Rules of Overriding

Method overriding is governed by a strict set of rules to ensure type safety and predictable behavior:

1. Signature Match: The method in the subclass must have the exact same name and parameter list as the method in the superclass.¹⁶
2. Return Type: The return type must be the same as the superclass method’s return type, or a subtype of it. The latter is known as a covariant return type.¹⁹
3. Access Modifier: The access level of the overriding method cannot be more restrictive than the overridden method. For example, a protected method in the superclass can be overridden as public in the subclass, but not as private or default (package-private).¹³
4. Ineligible Methods: Methods marked as final, static, or private in the superclass cannot be overridden. A final method is explicitly designed to be immutable. A static method belongs to the class, not an instance, and is hidden, not overridden. A private method is not visible to the subclass and thus cannot be overridden.¹⁷

The “Aha!” Moment: Polymorphism

With method overriding, we unlock one of the most powerful concepts in all of object-oriented programming: polymorphism.

The word “polymorphism” comes from Greek and means “many forms”.⁷

In Java, it is the ability of an object to be treated as an instance of its own class, its superclass, or any interface it implements.

The true magic happens when we invoke an overridden method.

Consider the following main method in our factory:

Java

// File: Factory.java
public class Factory {
    public static void main(String args) {
        // Create a generic Vehicle object.
        Vehicle myGenericVehicle = new Vehicle(“Ford”, “Transit”, 2020);

        // Create a Car object, but store it in a Vehicle reference variable.
        // This is possible because a Car IS-A Vehicle.
        Vehicle myCar = new Car(“Tesla”, “Model 3”, 2023, 4);

        System.out.println(“— Displaying Generic Vehicle Info —“);
        myGenericVehicle.displayInfo(); // Executes the method from the Vehicle class.

        System.out.println(“\n— Displaying Car Info (via Vehicle reference) —“);
        myCar.displayInfo(); // Executes the OVERRIDDEN method from the Car class.
    }
}

The output of this program will be:

— Displaying Generic Vehicle Info —
Vehicle: 2020 Ford Transit

— Displaying Car Info (via Vehicle reference) —
Vehicle: 2023 Tesla Model 3
Number of Doors: 4

This demonstrates the core of polymorphism.

Even though the myCar variable is of type Vehicle, the Java Virtual Machine (JVM) at runtime inspects the actual object that the variable refers to, which is a Car.

When displayInfo() is called, the JVM dynamically selects the most specific version of that method available for the actual object type.

This is known as runtime polymorphism or dynamic method dispatch.¹⁷

Polymorphism is the Purpose, Overriding is the Mechanism

It is crucial to understand that method overriding is not merely a feature for tweaking behavior.

It is the fundamental mechanism that enables the strategic purpose of polymorphism, which is a central pillar of object-oriented design.

The primary goal of a good software architecture is to build systems that are flexible and extensible.

Imagine if we had a list containing different types of vehicles and wanted to display information for all of them.

Without polymorphism, we would be forced to write brittle code full of type checks:

Java

// The BRITTLE way (without polymorphism)
for (Vehicle v : vehicleList) {
    if (v instanceof Car) {
        ((Car) v).displayCarInfo(); // Requires a special method
    } else if (v instanceof Motorcycle) {
        ((Motorcycle) v).displayMotorcycleInfo();
    } else {
        v.displayInfo();
    }
}

This code is a maintenance nightmare.

Every time we add a new type of vehicle, we must modify this loop.

Polymorphism solves this elegantly.

We can write simple, clean code that operates on the general Vehicle type, and trust the JVM to handle the details.

Java

// The FLEXIBLE way (with polymorphism)
for (Vehicle v : vehicleList) {
    v.displayInfo(); // The correct version is called automatically!
}

This loop is decoupled from the specific implementations.

We can add a Truck class, a Bus class, or a Spaceship class tomorrow, and as long as they extend Vehicle and override displayInfo(), this code will work perfectly without a single change.

This “pluggable” architecture, where client code is shielded from the specifics of the objects it manipulates, is the ultimate goal and the true power unlocked by method overriding.

Chapter 4: Expanding the Factory Floor – A Family of Classes

Our factory is growing.

We have a solid Vehicle blueprint and a specialized Car model.

Now, let’s expand our production line to illustrate the common inheritance patterns that Java supports, creating a true family of classes.³

Hierarchical Inheritance: One Parent, Many Children

The most common inheritance structure is hierarchical inheritance.

This occurs when a single superclass is extended by multiple, independent subclasses.³

Each subclass inherits the common traits of the parent but adds its own unique specializations.

This pattern is ideal when several distinct classes need to share a common set of core behaviors.³

Let’s add a Motorcycle to our factory.

Like a Car, a Motorcycle is also a Vehicle.

Java

// File: Motorcycle.java
public class Motorcycle extends Vehicle {
    private boolean hasSidecar;

    public Motorcycle(String make, String model, int year, boolean hasSidecar) {
        super(make, model, year);
        this.hasSidecar = hasSidecar;
    }

    @Override
    public void displayInfo() {
        super.displayInfo();
        System.out.println(“Has Sidecar: ” + this.hasSidecar);
    }
}

Now, our class structure looks like this: Vehicle is the parent to both Car and Motorcycle.

They share the Vehicle DNA but are distinct siblings in the hierarchy.

Multilevel Inheritance: A Chain of Ancestry

Next, we can create specializations of our specializations.

This forms a chain of inheritance known as multilevel inheritance, where a derived class becomes the base class for another new class.⁵

This is useful for creating progressively more specialized types in a step-by-step manner.³

Let’s design a SportsCar, which is a more specific type of Car.

Java

// File: SportsCar.java
public class SportsCar extends Car {
    private int topSpeed;

    public SportsCar(String make, String model, int year, int topSpeed) {
        // A sports car is a two-door car by our definition.
        super(make, model, year, 2);
        this.topSpeed = topSpeed;
    }

    // A new method specific to SportsCar
    public void engageTurbo() {
        System.out.println(“Turbo engaged! Prepare for ludicrous speed.”);
        // We can access the public accelerate() method inherited from Vehicle
        accelerate(50);
    }

    @Override
    public void displayInfo() {
        super.displayInfo(); // Calls Car’s displayInfo, which calls Vehicle’s
        System.out.println(“Top Speed: ” + this.topSpeed + ” mph”);
    }
}

The inheritance chain is now Vehicle → Car → SportsCar.

A SportsCar object inherits everything from Car, which in turn inherits everything from Vehicle.

This transitive nature of inheritance means a SportsCar has access to the methods and fields from all its ancestors in the chain.¹²

The Missing Pieces: Multiple and Hybrid Inheritance

A question naturally arises: if a class can have many children (hierarchical) and a child can have a child (multilevel), can a child have many parents? This concept is called multiple inheritance.

It is critical to understand that Java does not support multiple inheritance with classes.⁵

A Java class can extend one and only one other class.

This is not an oversight but a deliberate design decision made by the language’s creators to avoid a classic and thorny problem known as the

“Diamond Problem.”

Imagine we had two classes, LandVehicle and WaterVehicle, and both had a method called move().

If we then created a class AmphibiousCraft extends LandVehicle, WaterVehicle, which version of the move() method should it inherit? The one for driving on land or the one for sailing on water? This ambiguity is the Diamond Problem.

Languages like C++ that support multiple class inheritance have complex rules to resolve such conflicts.

The architects of Java opted for simplicity and predictability, deciding that the potential for confusion and error was too great.⁵

However, Java provides a powerful alternative for inheriting from multiple sources: interfaces.

An interface is a contract that defines a set of method signatures without providing an implementation.

A class can extend only one superclass, but it can implement many interfaces.

This allows a class to inherit multiple types or behaviors without inheriting conflicting implementations.

A combination of class inheritance and interface implementation is known as hybrid inheritance.

For instance, our SportsCar could extend Car and also implement RacingRegulations, inheriting both the state of a car and the contractual behaviors of a race-worthy vehicle.

This is Java’s safe and robust solution to the challenge of multiple inheritance.⁴

The following table summarizes the inheritance structures available in Java.

Inheritance Type	Description	Diagram	Our Factory Example
Single	A single subclass inherits from a single superclass. This is the foundation of all other types.	A -> B	Vehicle -> Car
Multilevel	A subclass inherits from a derived class, forming a chain of inheritance.	A -> B -> C	Vehicle -> Car -> SportsCar
Hierarchical	Multiple subclasses inherit from a single superclass.	A -> B A -> C	Vehicle -> Car Vehicle -> Motorcycle

Chapter 5: An Architect’s Warning – The Fragile Base Class Problem

Thus far, our journey has been that of a developer learning the tools of the trade.

We have seen how to build classes that reuse code and create flexible systems.

Now, we must shift our perspective to that of a software architect—one who is concerned not just with what a tool can do, but with the long-term consequences of using it.

Inheritance, for all its power, carries a significant risk known as the fragile base class problem.

This is a fundamental architectural issue where seemingly safe and minor modifications to a superclass can unexpectedly break the functionality of its subclasses, even if the subclass code itself is not touched.²²

A Concrete Example of Fragility

To understand this danger, let’s step away from our vehicle factory and consider a classic example involving Java’s collection framework.²⁴

Suppose we want to create a specialized

HashSet that counts the total number of elements ever added to it.

We might create a new class, InstrumentedHashSet, that extends HashSet.

HashSet has two methods for adding elements: add(E element) and addAll(Collection<? extends E> c).

To count all additions, we must override both.

Java

// An example of a fragile subclass
public class InstrumentedHashSet<E> extends HashSet<E> {
    private int addCount = 0;

    public InstrumentedHashSet() {}

    @Override
    public boolean add(E e) {
        addCount++;
        return super.add(e);
    }

    @Override
    public boolean addAll(Collection<? extends E> c) {
        addCount += c.size();
        return super.addAll(c);
    }

    public int getAddCount() {
        return addCount;
    }
}

This code seems logical.

We increment our counter in both methods that can add elements.

Now, let’s test it:

Java

InstrumentedHashSet<String> s = new InstrumentedHashSet<>();
s.addAll(Arrays.asList(“Snap”, “Crackle”, “Pop”));
System.out.println(“Elements added: ” + s.getAddCount()); // Expected: 3

The output is not 3.

It is 6.

What went wrong? The subclass broke because it relied on an implementation detail of its superclass that it could not see.

The internal implementation of the HashSet class’s addAll method is written to simply iterate over the incoming collection and call its own add method for each element.

Our InstrumentedHashSet called super.addAll(), which in turn called our overridden add() method three times.

We incremented the counter once in addAll (by 3) and then three more times in add (by 1 each time), resulting in a total count of 6.

Our subclass is fragile; its correctness depends entirely on the hidden implementation of its parent.

Inheritance Violates Encapsulation

The root cause of the fragile base class problem is that implementation inheritance fundamentally violates encapsulation.

Encapsulation dictates that a class should hide its internal workings from the outside world, exposing only a well-defined public interface.¹⁵

However, when a subclass

extends a superclass, it is not merely inheriting a public API; it is becoming intimately tied to the superclass’s implementation.²⁵

The subclass’s behavior is now intrinsically linked to the parent’s private and protected methods and how they interact with each other.

This creates a tight coupling between the superclass and the subclass.¹⁵

They can no longer evolve independently.

The author of the superclass cannot freely refactor its internal logic without risking the silent breakage of countless subclasses they may not even know exist.

This places a massive maintenance burden on the creator of the base class.

This leads to the architect’s primary rule for inheritance, famously articulated by Joshua Bloch in Effective Java: “Design and document for inheritance or else prohibit it”.²²

This means that a class should only be considered safe for extension if its author has explicitly designed it for that purpose, carefully documenting how its internal methods interact (its “self-use” patterns) and what can be safely overridden.

If a class is not designed this way, inheritance should be forbidden by marking the class with the

final keyword, which prevents any other class from extending it.²³

Chapter 6: A Superior Blueprint – Favoring Composition Over Inheritance

Given the significant risks of implementation inheritance, the modern consensus among software architects is to follow a different principle: favor composition over inheritance.²⁷

This approach offers a more flexible, robust, and maintainable way to achieve code reuse and build complex systems.

“Has-A” vs. “Is-A”

The core difference between the two models lies in the relationship they represent:

• Inheritance models an “is-a” relationship. A Car is a Vehicle. It is a relationship of identity and classification.³⁰
• Composition models a “has-a” relationship. A Car has an Engine. It is a relationship of ownership and components.³⁰ Composition is about building complex objects by assembling, or
  composing, them from smaller, independent, and often interchangeable parts.²⁸

Refactoring Our Factory with Composition

Let’s apply this principle to our factory.

Instead of thinking of a vehicle’s engine as an inherited property, let’s model it as a separate, self-contained component.

First, we create an Engine class:

Java

// File: Engine.java
public class Engine {
    private String type;

    public Engine(String type) {
        this.type = type;
    }

    public void start() {
        System.out.println(type + ” engine started.”);
    }

    public void stop() {
        System.out.println(type + ” engine stopped.”);
    }
}

Now, instead of having our Car class extend some kind of EngineVehicle, we simply give it an Engine instance as a field.

The Car class now contains an Engine.

Java

// A Car class using composition
public class Car {
    private String make;
    private String model;
    private Engine engine; // Composition: Car HAS-A Engine

    public Car(String make, String model, Engine engine) {
        this.make = make;
        this.model = model;
        this.engine = engine; // The Car is given its component
    }

    public void startCar() {
        // Delegation: The Car delegates the start task to its Engine component
        System.out.println(“Turning key for ” + make + ” ” + model + “…”);
        engine.start();
    }

    public void stopCar() {
        engine.stop();
    }
}

In this model, the Car achieves its functionality not by inheriting it, but by delegating the work to its internal components.²⁵

When

startCar() is called, the Car object forwards the call to its engine object.

This is also known as forwarding.

The Overwhelming Benefits of Composition

This compositional design provides numerous advantages over an inheritance-based model:

1. Flexibility: This is the most significant benefit. The relationship is established at runtime, not compile time. We can easily create a Car with different types of engines by simply passing a different Engine object to its constructor. We could have a V8Engine or an ElectricMotor class (both could implement an IEngine interface), and the Car class wouldn’t need to change at all. This level of dynamic flexibility is impossible with the rigid, compile-time binding of inheritance.²⁶
2. Loose Coupling: The Car class is completely decoupled from the implementation of the Engine class. It only depends on the Engine’s public API (start() and stop()). The internal workings of the Engine can be changed, refactored, or completely replaced without any risk of breaking the Car class. This effectively solves the fragile base class problem.²⁶
3. Strong Encapsulation: The internal state and logic of the Engine are perfectly encapsulated and hidden from the Car. The Car cannot accidentally interfere with the Engine’s implementation.³⁰
4. Improved Testability: Unit testing becomes much simpler. When testing the Car class, we can provide a “mock” Engine object that simulates engine behavior. This allows us to test the Car in isolation, without any dependency on a real, complex Engine component.²⁶

The following table provides a strategic comparison to guide the decision between inheritance and composition.

Aspect	Inheritance	Composition
Relationship	“is-a”	“has-a”
Coupling	Tight (subclass depends on superclass implementation)	Loose (class depends only on component’s public interface)
Flexibility	Rigid (defined at compile-time)	Flexible (can be changed at run-time)
Code Reuse	Reuses implementation and interface	Reuses interface via delegation
Key Principle	Extending what an object is	Composing what an object can do

Conclusion: The Master Builder’s Toolkit

Our journey through the Vehicle Factory has taken us from the foundational syntax of Java inheritance to the high-level strategic decisions of software architecture.

We began by crafting a simple Vehicle blueprint, learning how to create specialized subclasses like Car and SportsCar using the extends and super keywords.

We saw how to customize behavior with method overriding and, in doing so, unlocked the transformative power of polymorphism, which enables the creation of flexible and extensible systems.

But our journey did not end there.

We then adopted the critical eye of an architect and recognized the inherent dangers of this powerful tool.

We discovered that implementation inheritance can lead to the fragile base class problem by violating encapsulation and creating tightly coupled, brittle code.

This led us to a superior blueprint: the principle of favoring composition over inheritance.

By building objects from independent, swappable components, we learned to create systems that are more flexible, more robust, and far easier to maintain and test.

Inheritance is not an inherently “bad” feature.

It remains a valid and necessary tool for modeling true “is-a” relationships, especially within a package where the code is controlled by the same team or when designing a class hierarchy that strictly adheres to the Liskov Substitution Principle.

However, it is a specialized instrument, to be used with caution and deliberation.

For the vast majority of code reuse and functionality extension scenarios, composition provides a safer and more powerful alternative.

A master builder knows every tool in their toolkit, but their true expertise lies in knowing precisely when, and when not, to use each one.

This discerning judgment is the hallmark of a true software architect.

Works cited

1. Inheritance – Dev.java, accessed on August 10, 2025, https://dev.java/learn/inheritance/
2. What Is Inheritance? (The Java™ Tutorials > Learning the Java Language > Object-Oriented Programming Concepts), accessed on August 10, 2025, https://docs.oracle.com/javase/tutorial/java/concepts/inheritance.html
3. Types of Inheritance in Java: Key Concepts, Benefits and Challenges in 2025 – upGrad, accessed on August 10, 2025, https://www.upgrad.com/blog/types-of-inheritance-in-java/
4. Inheritance in Java – GeeksforGeeks, accessed on August 10, 2025, https://www.geeksforgeeks.org/java/inheritance-in-java/
5. What is Inheritance in Java? : r/programming – Reddit, accessed on August 10, 2025, https://www.reddit.com/r/programming/comments/t2ptpo/what_is_inheritance_in_java/
6. Inheritance (The Java™ Tutorials > Learning the Java Language …, accessed on August 10, 2025, https://docs.oracle.com/javase/tutorial/java/IandI/subclasses.html
7. Learn Java: Inheritance and Polymorphism Cheatsheet – Codecademy, accessed on August 10, 2025, https://www.codecademy.com/learn/learn-java/modules/learn-java-inheritance-and-polymorphism/cheatsheet
8. Summary of Inheritance – The Java™ Tutorials, accessed on August 10, 2025, https://docs.oracle.com/javase/tutorial/java/IandI/summaryinherit.html
9. Lesson: Interfaces and Inheritance (The Java™ Tutorials > Learning the Java Language), accessed on August 10, 2025, https://docs.oracle.com/javase/tutorial/java/IandI/index.html
10. Questions and Exercises: Inheritance (The Java™ Tutorials > Learning the Java Language > Interfaces and Inheritance), accessed on August 10, 2025, https://docs.oracle.com/javase/tutorial/java/IandI/QandE/inherit-questions.html
11. extends Keyword in Java: Usage & Examples – DataCamp, accessed on August 10, 2025, https://www.datacamp.com/doc/java/extends
12. Java Inheritance – Types & Importance of Inheritance with Real-life Examples! – TechVidvan, accessed on August 10, 2025, https://techvidvan.com/tutorials/java-inheritance/
13. Java Method Overriding – Programiz, accessed on August 10, 2025, https://www.programiz.com/java-programming/method-overriding
14. Using the Keyword super – Java™ Tutorials, accessed on August 10, 2025, https://docs.oracle.com/javase/tutorial/java/IandI/super.html
15. Demystifying the Dark Side: Disadvantages of Inheritance in Java – 30 Days Coding, accessed on August 10, 2025, https://30dayscoding.com/blog/disadvantages-of-inheritance-in-java
16. Method overriding – Wikipedia, accessed on August 10, 2025, https://en.wikipedia.org/wiki/Method_overriding
17. Method overriding in java with example – BeginnersBook, accessed on August 10, 2025, https://beginnersbook.com/2014/01/method-overriding-in-java-with-example/
18. Overriding in Java – GeeksforGeeks, accessed on August 10, 2025, https://www.geeksforgeeks.org/java/overriding-in-java/
19. Overriding and Hiding Methods (The Java™ Tutorials > Learning the Java Language > Interfaces and Inheritance), accessed on August 10, 2025, https://docs.oracle.com/javase/tutorial/java/IandI/override.html
20. Types of inheritance in Java: Single,Multiple,Multilevel & Hybrid – BeginnersBook, accessed on August 10, 2025, https://beginnersbook.com/2013/05/java-inheritance-types/
21. Types of Inheritance in Java: A Comprehensive Guide | by Ruhiparveen – Medium, accessed on August 10, 2025, https://medium.com/@ruhiparveen310/types-of-inheritance-in-java-a-comprehensive-guide-b2aa658754fb
22. Fragile base class – Wikipedia, accessed on August 10, 2025, https://en.wikipedia.org/wiki/Fragile_base_class
23. What is the fragile base class problem? – java – Stack Overflow, accessed on August 10, 2025, https://stackoverflow.com/questions/2921397/what-is-the-fragile-base-class-problem
24. Problems With Inheritance in Java – DZone, accessed on August 10, 2025, https://dzone.com/articles/problems-with-inheritance-in-java
25. You should favor composition over inheritance in Java. Here’s why. – Oracle Blogs, accessed on August 10, 2025, https://blogs.oracle.com/javamagazine/post/java-inheritance-composition
26. Composition vs Inheritance | DigitalOcean, accessed on August 10, 2025, https://www.digitalocean.com/community/tutorials/composition-vs-inheritance
27. Code Smell: Inheritance Abuse [duplicate] – Software Engineering Stack Exchange, accessed on August 10, 2025, https://softwareengineering.stackexchange.com/questions/12439/code-smell-inheritance-abuse
28. Composition over inheritance – Wikipedia, accessed on August 10, 2025, https://en.wikipedia.org/wiki/Composition_over_inheritance
29. Composition over Inheritance – Medium, accessed on August 10, 2025, https://medium.com/hprog99/composition-over-inheritance-a5f02a820eb0
30. Favoring Composition Over Inheritance In Java With Examples – GeeksforGeeks, accessed on August 10, 2025, https://www.geeksforgeeks.org/java/favoring-composition-over-inheritance-in-java-with-examples/
31. Composition vs. Inheritance: A Detailed Comparison | by Reetesh Kumar | Medium, accessed on August 10, 2025, https://medium.com/@reetesh043/composition-vs-inheritance-a-detailed-comparison-89f87007a7c5