Composition vs Inheritance in Java OOP Design

Deciding how to structure classes and objects is one of the most important aspects of object-oriented programming in Java. Two of the primary ways to establish relationships between classes are composition and inheritance. Each has its own advantages and trade-offs, and knowing when to apply either approach can significantly affect the maintainability, flexibility, and clarity of your code.

In this article, I’ll share my insights on composition vs inheritance in Java OOP design. I will explain what each technique involves, illustrate how they work in Java, compare their pros and cons, and discuss when to favor one over the other. Using examples from my experience, I’ll also highlight common pitfalls to avoid and best practices to follow.

How Inheritance Shapes Java Classes

Inheritance is one of the core pillars of object-oriented programming. It enables a new class (called a subclass or child class) to inherit fields and methods from an existing class (called a superclass or parent class). This models an “is-a” relationship. For example, if you have a Vehicle class, you might create a subclass Car that inherits from Vehicle because a car is a vehicle.

Here’s a basic example of inheritance in Java:

java public class Vehicle {
    public void startEngine() {
        System.out.println("Engine started");
    }
}

public class Car extends Vehicle {
    public void openTrunk() {
        System.out.println("Trunk opened");
    }
}

By extending Vehicle, the Car class automatically gets the startEngine() method. This avoids code duplication and models natural hierarchies.

I’ve found inheritance convenient when the subclass truly is a specialized type of the superclass. It allows me to reuse code easily and override behavior to customize functionality.

However, inheritance can also lead to tight coupling. Subclasses depend heavily on the implementation of their parents, making changes more complicated. If the superclass changes, it might break subclasses unexpectedly.

Composition Builds Classes from Parts

Composition takes a different approach. Instead of inheriting from a superclass, a class includes instances of other classes as fields. This models a “has-a” relationship.

For example, a Car might have an Engine as one of its components:

java public class Engine {
    public void start() {
        System.out.println("Engine started");
    }
}

public class Car {
    private Engine engine;

    public Car() {
        engine = new Engine();
    }

    public void startCar() {
        engine.start();
    }
}

Here, Car has an Engine. The Car delegates the starting action to its engine component.

I often prefer composition because it creates more flexible and loosely coupled designs. You can swap out parts easily, and each class can focus on a specific responsibility. Composition also avoids some problems inheritance introduces, such as the fragile base class problem, where changes to the superclass can inadvertently affect subclasses.

Comparing Composition vs Inheritance in Java OOP Design

The choice between composition and inheritance is rarely black and white. It depends on your design goals and specific use cases. Here are some factors I consider:

Flexibility and Extensibility

Inheritance ties a subclass to the superclass’s interface and implementation. If the superclass changes, subclasses may need updates. This can make refactoring tricky.

Composition offers more flexibility. You can replace components without changing the containing class’s interface. For example, you can swap one Engine implementation for another without touching the Car class.

Code Reuse

Inheritance encourages reuse by sharing code in a common superclass. However, it can lead to deep and complex class hierarchies that are difficult to maintain.

Composition achieves reuse by assembling objects with reusable parts. It promotes better separation of concerns and makes each class easier to test in isolation.

Modeling Relationships

Use inheritance when there’s a clear “is-a” relationship, like Car is a Vehicle. Use composition to model “has-a” relationships, such as a Car has an Engine or a House has a Door.

Avoiding Fragility

In my experience, deep inheritance hierarchies often introduce fragility. Modifying a superclass can cascade bugs down the hierarchy. Composition reduces this risk by decoupling components.

Multiple Behaviors

Java does not support multiple inheritance of classes (only multiple interfaces). This limits inheritance’s ability to combine behaviors from multiple sources.

Composition, however, allows you to assemble an object with various behaviors by including different components.

Examples That Illustrate the Trade-Offs

Example 1: Inheritance Leading to Fragile Design

Suppose you have a Bird class and subclasses Penguin and Eagle. The superclass Bird includes a method fly().

java public class Bird {
    public void fly() {
        System.out.println("Flying");
    }
}

public class Penguin extends Bird {
    // Penguins cannot fly
}

Here, Penguin inherits a method fly() that does not make sense. This violates the Liskov Substitution Principle because Penguin cannot behave like a Bird that flies.

Composition helps avoid this:

java public interface Flyable {
    void fly();
}

public class FlyingBehavior implements Flyable {
    public void fly() {
        System.out.println("Flying");
    }
}

public class Bird {
    private Flyable flyingBehavior;

    public Bird(Flyable flyingBehavior) {
        this.flyingBehavior = flyingBehavior;
    }

    public void performFly() {
        flyingBehavior.fly();
    }
}

public class Penguin extends Bird {
    public Penguin() {
        super(() -> System.out.println("Cannot fly"));
    }
}

This way, behavior is flexible and classes are composed with the behaviors they need.

Example 2: Composition for Greater Flexibility

Consider a Printer class that can print documents and also scan them.

java public interface Printable {
    void print();
}

public interface Scannable {
    void scan();
}

public class BasicPrinter implements Printable {
    public void print() {
        System.out.println("Printing document");
    }
}

public class AdvancedPrinter implements Printable, Scannable {
    public void print() {
        System.out.println("Printing document");
    }
    public void scan() {
        System.out.println("Scanning document");
    }
}

Instead of creating subclasses like PrinterWithScanner that inherits Printer, I compose a MultifunctionPrinter class by combining interfaces and implementations.

When to Use Inheritance

I rely on inheritance when:

• There is a natural is-a relationship.
• Behavior and properties are shared and unlikely to change.
• Extending existing functionality fits my design.
• I want to leverage polymorphism via method overriding.

However, I make sure the hierarchy stays shallow and logical.

When to Prefer Composition

Composition becomes my go-to choice when:

• I want to build complex objects by combining simple, reusable components.
• I want loose coupling between classes.
• The system requires more flexibility and easier maintenance.
• I need to change behavior at runtime or swap components.
• Multiple behaviors need to be combined.

The Principle “Favor Composition Over Inheritance”

This phrase is often repeated in design discussions, and I fully agree with it based on experience. Composition typically leads to more maintainable and adaptable code. It aligns with the single responsibility principle by delegating tasks to specialized components.

Inheritance is useful, but it should be applied sparingly and thoughtfully.

Avoiding Common Pitfalls

Overusing Inheritance

Relying too heavily on inheritance can create fragile code and violate encapsulation. I avoid building deep inheritance trees and keep parent classes focused and stable.

Neglecting Encapsulation with Composition

Even when using composition, I protect the internal components from being accessed or modified directly. I expose only necessary behaviors through well-defined interfaces.

Confusing Has-A and Is-A

I always carefully analyze the relationship. If a subclass cannot truly behave like the superclass, inheritance is not appropriate.

Real-World Scenario: Designing a Media Player

Imagine designing a media player that can play audio and video files.

Using inheritance, I might create a superclass MediaPlayer with subclasses AudioPlayer and VideoPlayer. But what if I want a player that can do both?

With composition, I can design separate classes AudioModule and VideoModule and compose a MediaPlayer class that holds references to these modules.

java public class AudioModule {
    public void playAudio() {
        System.out.println("Playing audio");
    }
}

public class VideoModule {
    public void playVideo() {
        System.out.println("Playing video");
    }
}

public class MediaPlayer {
    private AudioModule audioModule;
    private VideoModule videoModule;

    public MediaPlayer() {
        audioModule = new AudioModule();
        videoModule = new VideoModule();
    }

    public void playAudio() {
        audioModule.playAudio();
    }

    public void playVideo() {
        videoModule.playVideo();
    }
}

This design is much more flexible and easier to extend with other modules, like subtitles or playlists.

Conclusion

The choice between composition vs inheritance in Java OOP design is pivotal to building strong software systems. Both techniques have their place, and knowing when and how to apply them is vital.

Inheritance shines when you have clear is-a relationships and want to reuse or extend behavior through class hierarchies. Composition excels when you want flexibility, modularity, and loose coupling by assembling objects from reusable parts.

Over time, I’ve learned to lean toward composition for most designs, using inheritance carefully and sparingly. Applying this mindset helps me write code that is easier to maintain, test, and evolve.

By carefully considering your design goals and the relationships between classes, you can make informed choices about composition vs inheritance in Java OOP design that will serve your projects well.