System Design (LLD)Favor Composition Over Inheritance

Favor Composition Over Inheritance — The Critical Design Choice

LevelIntermediate

Duration60 mins

TopicFavor Composition Over Inheritance

1 / 4

The 'Favor Composition Over Inheritance' Principle Explained

The Principle That Shaped Modern Software Design

In the landscape of software design principles, few have had as profound an impact as the maxim: "Favor Composition Over Inheritance."

This deceptively simple statement, popularized by the legendary Gang of Four (GoF) in their seminal 1994 book Design Patterns: Elements of Reusable Object-Oriented Software, has fundamentally reshaped how expert practitioners approach object-oriented design. It represents a paradigm shift from the inheritance-centric thinking that dominated early OOP education to a more nuanced, flexible approach that prioritizes object composition.

Understanding this principle deeply is essential. It separates engineers who write rigid, fragile hierarchies from those who craft systems that gracefully adapt to changing requirements.

What You Will Learn

By the end of this page, you will understand the historical origins of this principle, the fundamental problems it addresses, and the core philosophy that makes it one of the most cited guidelines in object-oriented design. You'll grasp why this isn't anti-inheritance dogma, but rather a nuanced heuristic born from decades of industry experience.

The Historical Context

To understand why "favor composition over inheritance" became a foundational principle, we must first understand the context in which it emerged.

The Early Promise of Inheritance

When object-oriented programming gained mainstream adoption in the 1980s and 1990s, inheritance was celebrated as a revolutionary mechanism for code reuse. The promise was compelling:

Define common behavior in base classes
Specialize through subclasses
Share code effortlessly through the inheritance chain

Early OOP textbooks and courses heavily emphasized inheritance. Class hierarchies became the primary organizational structure. The ability to model "is-a" relationships felt natural and powerful.

The Inheritance Honeymoon Phase

•Academic enthusiasm — Universities taught inheritance as the cornerstone of OOP, often before students encountered real-world complexity.
•Simple examples worked beautifully — The canonical Animal → Dog → Beagle hierarchies were intuitive and clean.
•Code reuse seemed magical — Define once in the parent, use everywhere in children.
•Polymorphism through inheritance — A unified mechanism for achieving type flexibility.
•Framework design centered on inheritance — Early UI frameworks (MFC, early Java AWT) relied heavily on inheritance for extension.

The Reality Check

As systems grew larger and evolved over time, the cracks began to appear. Engineers maintaining production systems discovered that inheritance hierarchies, once established, became increasingly difficult to change. The elegant class trees from design documents calcified into rigid structures that resisted modification.

By the mid-1990s, experienced practitioners had accumulated enough battle scars to articulate what wasn't working. The Gang of Four crystallized this wisdom in a single, powerful recommendation.

The Gang of Four's Original Statement

"Favor object composition over class inheritance."

This appears in Chapter 1 of Design Patterns, where the authors dedicate significant discussion to the limitations of inheritance and the advantages of composition. The entire patterns catalog that follows demonstrates techniques for achieving flexibility through composition.

What the Principle Actually Means

Before diving deeper, let's establish precise definitions. The principle involves two distinct mechanisms for sharing behavior and building complex objects:

Class Inheritance ("White-Box Reuse")

Inheritance creates a subtype relationship where a child class inherits implementation from a parent class. The internals of the parent are visible to the child:

Child classes automatically receive parent behavior
Children can override parent methods
Children have access to protected parent members
The relationship is static—defined at compile time
Children are coupled to the parent's implementation details

Object Composition ("Black-Box Reuse")

Composition creates a "has-a" relationship where one object contains references to other objects and delegates behavior to them:

Objects collaborate by sending messages to contained objects
Behavior is acquired through delegation, not inheritance
The contained objects' internals remain hidden
Relationships can be changed at runtime
Objects are coupled only to interfaces, not implementations

Inheritance vs Composition: Fundamental Comparison
Aspect	Inheritance (White-Box)	Composition (Black-Box)
Relationship	IS-A (type relationship)	HAS-A (ownership/collaboration)
Coupling	High—child knows parent internals	Low—only interface contracts
Binding Time	Compile-time (static)	Runtime (dynamic)
Visibility	Protected/public parent members visible	Only public interface visible
Reuse Mechanism	Inheriting implementation	Delegating to contained objects
Change Impact	Parent changes break children	Internal changes are hidden
Flexibility	Fixed at design time	Can change at runtime

The "Favor" in "Favor Composition"

Critically, the principle says "favor," not "always use." This is a heuristic, not a commandment:

When both approaches could work, prefer composition
Make inheritance the justified exception, not the default
Consider inheritance only when there's a true "is-a" relationship with behavioral substitutability
Use inheritance when you need to participate in a framework that requires it

The principle acknowledges that inheritance has legitimate uses. It simply argues that composition should be your first instinct because it provides superior flexibility in most scenarios.

The Decision Heuristic

When you find yourself about to create a subclass, pause and ask: "Could I achieve this with composition instead?" If yes, composition is usually the better choice. If you genuinely need polymorphic substitutability and have a true is-a relationship with behavioral compatibility, inheritance may be appropriate.

The Problems With Inheritance

To understand why the principle emerged, we must deeply understand the problems that inheritance creates. These aren't theoretical concerns—they're hard-won lessons from decades of maintaining production systems.

The Four Deadly Problems of Inheritance

•The Fragile Base Class Problem — Changes to a base class can unexpectedly break subclasses, even when the base class's public interface remains unchanged. The coupling is so tight that internal implementation changes propagate outward.
•The Tight Coupling Problem — Subclasses are intimately tied to their parent's implementation. They depend not just on the interface, but on how the parent implements that interface internally.
•The Rigid Hierarchy Problem — Once established, inheritance hierarchies are difficult to restructure. Adding new variations often requires modifying existing classes or introducing awkward intermediate base classes.
•The Composition Explosion Problem — When you need to combine behaviors from multiple sources, single inheritance languages force you into awkward workarounds, while multiple inheritance creates its own complexity (the diamond problem).

Deep Dive: The Fragile Base Class Problem

Consider a Window base class with a method display() that calls a protected helper method renderBorder(). A subclass FancyWindow overrides renderBorder() to draw a decorative border.

Six months later, a developer working on the base class optimizes display() to cache the border rendering. They change the implementation to call renderBorder() only on first display. This seemingly innocent optimization breaks FancyWindow—rendering is now cached incorrectly because the base class made assumptions about how renderBorder() would be called.

The subclass author and the base class author made reasonable decisions independently. Neither violated any contract. Yet the system broke.

This is the insidious nature of inheritance coupling: you depend on implementation details that aren't part of the public contract, and you often don't know it until something breaks.

fragile-base-class-example
Java
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
// The Fragile Base Class Problem Illustrated
 
// ORIGINAL BASE CLASS (v1.0)
public class Window {
    protected void renderBorder() {
        // Default border rendering
        Graphics.drawRectangle(bounds);
    }
    
    public void display() {
        renderBorder();
        renderContent();
    }
}
 
// SUBCLASS - works fine with v1.0
public class FancyWindow extends Window {
    @Override
    protected void renderBorder() {
        // Custom decorative border
        Graphics.drawDecorativeBorder(bounds);
        playAnimation();
    }
}
 
// BASE CLASS MODIFICATION (v1.1) - "optimization"
public class Window {
    private boolean borderCached = false;
    
    protected void renderBorder() {
        Graphics.drawRectangle(bounds);
    }
    
    public void display() {
        // "Safe" optimization - call renderBorder only once
        if (!borderCached) {
            renderBorder();
            borderCached = true;
        }
        renderContent();
    }
}
 
// PROBLEM: FancyWindow is now broken!
// - Animation plays only once (first display)
// - Resizing doesn't update the decorative border
// - The subclass author made no mistakes
// - The base class author made no mistakes
// - Yet the system is broken due to implicit coupling

The Hidden Contract Problem

Inheritance creates implicit contracts beyond the explicit interface. Subclasses depend on when, how, and in what order parent methods are called. These dependencies are rarely documented and often not even recognized until they're violated.

The Composition Alternative

Composition solves these problems by fundamentally changing how objects share behavior. Instead of inheriting implementation, objects delegate to collaborators:

Key Insight: With composition, you compose behavior by combining objects that each contribute specific capabilities. Changes to one component's internals don't affect others because the coupling is limited to well-defined interfaces.

Let's reimagine the FancyWindow example using composition:

composition-solution
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
// The Composition Solution
 
// Define a contract for border rendering
public interface BorderRenderer {
    void render(Rectangle bounds);
}
 
// Different border implementations
public class SimpleBorderRenderer implements BorderRenderer {
    @Override
    public void render(Rectangle bounds) {
        Graphics.drawRectangle(bounds);
    }
}
 
public class DecorativeBorderRenderer implements BorderRenderer {
    @Override
    public void render(Rectangle bounds) {
        Graphics.drawDecorativeBorder(bounds);
        playAnimation();
    }
}
 
// Window uses composition instead of inheritance
public class Window {
    private BorderRenderer borderRenderer;
    
    public Window(BorderRenderer borderRenderer) {
        this.borderRenderer = borderRenderer;
    }
    
    public void display() {
        borderRenderer.render(bounds);  // Delegate to component
        renderContent();
    }
    
    // Can even change at runtime!
    public void setBorderRenderer(BorderRenderer renderer) {
        this.borderRenderer = renderer;
    }
}
 
// Usage - Behavior is composed, not inherited
Window fancyWindow = new Window(new DecorativeBorderRenderer());
Window simpleWindow = new Window(new SimpleBorderRenderer());
 
// Runtime flexibility
fancyWindow.setBorderRenderer(new SimpleBorderRenderer());  // Change behavior!

Notice what composition provides:

Explicit Dependencies — The Window class clearly declares it needs a BorderRenderer. No hidden coupling.
Implementation Isolation — How DecorativeBorderRenderer works internally is completely hidden from Window. Changes to the renderer don't affect Window.
Runtime Flexibility — Behavior can be swapped at runtime. The same Window instance can have different renderers at different times.
Easy Testing — Mock or stub the BorderRenderer interface to test Window in isolation.
Independent Evolution — The BorderRenderer implementations can evolve independently of Window.

Inheritance Approach

•Behavior fixed at compile time
•Subclass coupled to parent implementation
•Parent changes may break subclasses
•Testing requires the entire hierarchy
•One inheritance chain per class

Composition Approach

•Behavior changeable at runtime
•Components coupled only to interfaces
•Component internals are encapsulated
•Components can be tested independently
•Unlimited component combinations

The Philosophy Behind the Principle

Understanding the deeper philosophy helps internalize this principle as a way of thinking, not just a rule to follow.

Prefer Black-Box Over White-Box Reuse

The Gang of Four distinguished between "white-box" reuse (inheritance) and "black-box" reuse (composition):

White-box: You see inside the box (parent class internals visible to subclasses)
Black-box: You interact only with the surface (interface contracts)

Black-box reuse is more robust because it limits your dependencies to the surface. You don't know—and don't need to know—what's inside the box. This ignorance is protective.

The Information Hiding Principle Connection

Preferring composition aligns with Parnas's Information Hiding principle (1972): design modules to hide their implementation decisions. Inheritance explicitly exposes implementation; composition respects boundaries.

Design for Change

The fundamental assumption behind "favor composition" is that requirements change. Software that cannot adapt is software that will eventually be replaced.

Inheritance hierarchies optimize for the current understanding of the domain. Composition optimizes for unknown future changes. Given that we cannot predict the future, composition is the safer bet.

Aggregate, Don't Inherit

Rather than thinking "X is a Y," train yourself to think "X has a Y" or "X uses a Y":

Instead of SportsCar extends Car → Car has an Engine (or PerformanceEngine)
Instead of Manager extends Employee → Employee has a Role (possibly ManagerRole)
Instead of FileLogger extends Logger → Logger uses a LogDestination (could be FileDestination)

This mental shift opens up flexibility: an Employee can change roles, a Car can have its engine upgraded, a Logger can switch destinations at runtime.

Thinking Inheritance vs Thinking Composition
Inheritance Thinking	Composition Thinking
"X is a specialized Y"	"X uses Y's capabilities"
"Define a subtype"	"Assemble from parts"
"Override parent behavior"	"Delegate to collaborators"
"Extend the hierarchy"	"Add a new component type"
"This class IS an animal"	"This object HAS movement behavior"

Industry Validation

This isn't just theoretical—the principle has been validated across decades of industry practice:

Framework Evolution

Compare the design of early vs modern frameworks:

Early frameworks (1990s) — Required extensive inheritance. To use the framework, you extended their base classes (Template Method pattern everywhere).
Modern frameworks (2010s–present) — Prefer composition, dependency injection, and interfaces. You provide implementations of small interfaces that the framework orchestrates.

This evolution reflects hard-learned lessons about maintainability.

Modern Design Approach Examples

•Go's composition model — Go famously has no inheritance at all. All code reuse is through composition and interfaces. This was a deliberate design choice based on the principle.
•Rust's trait system — Rust uses traits (interface-like contracts) and composition. There's no class inheritance hierarchy.
•React's component model — React moved from class inheritance (React.Component) to function components with hooks—a pure composition model.
•Microservices architecture — Services compose to form systems. No service "inherits" from another; they collaborate through APIs.
•Entity-Component-System (ECS) — Modern game engines use ECS, which is pure composition. Entities have components; there's no entity inheritance.

What the Experts Say

Beyond the Gang of Four, numerous authoritative voices have reinforced this principle:

"Inheritance is a powerful way to achieve code reuse, but it is not always the best tool for the job. Used inappropriately, it leads to fragile software." — Joshua Bloch, Effective Java

"The problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle." — Joe Armstrong, Creator of Erlang

"Prefer composition over inheritance. It's more flexible and avoids the fragile base class problem." — Robert C. Martin (Uncle Bob)

A Principle That Transcends Languages

Whether you write Java, Python, TypeScript, or any other OOP language, this principle applies. It's about the way you structure relationships between collaborating parts—a design concern that transcends syntax.

Common Misconceptions

The principle is frequently misunderstood. Let's clarify what it does not mean:

What the Principle Does NOT Mean

•"Never use inheritance" — Inheritance has valid uses. The principle says favor composition when both approaches could work. Some situations genuinely call for inheritance.
•"Inheritance is bad" — Inheritance is a legitimate language feature. It's the default, reflexive use of inheritance that causes problems.
•"Always add an interface between everything" — Over-abstraction is its own problem. The principle guides toward flexibility, not unnecessary complexity.
•"Composition means more code" — While composition may require more explicit wiring, this explicitness often reduces bugs and makes the code more maintainable.
•"This only applies to class design" — The principle's philosophy (prefer smaller, recombinable units over rigid hierarchies) applies to modules, services, and systems—not just classes.

The Balance Point

Dogmatically avoiding inheritance is as harmful as dogmatically using it. The goal is thoughtful selection of the right tool. Ask "is inheritance justified here?" rather than reflexively inheriting or reflexively rejecting inheritance.

When Inheritance IS Appropriate

Despite favoring composition, inheritance remains appropriate when:

True is-a relationships with behavioral compatibility — When the subtype genuinely is substitutable for the parent in all contexts (Liskov Substitution Principle).
Framework extension points designed for inheritance — When the framework expects you to extend a class and override specific methods (Template Method pattern).
Immutable value hierarchies — Inheritance works well for immutable value types where behavior won't change dynamically.
Closed hierarchies — When you control all descendants and the hierarchy is stable and unlikely to change.

These cases are the exception, not the default. The burden of proof should be on inheritance.

Summary: The Foundational Principle

We've established the core understanding of "Favor Composition Over Inheritance." Let's consolidate the key points:

Key Takeaways

•Historical origin — The principle emerged from the Gang of Four's distillation of industry wisdom about the problems with inheritance-heavy designs.
•Inheritance creates tight coupling — Subclasses depend on parent implementation details, creating the fragile base class problem and rigid hierarchies.
•Composition provides loose coupling — Objects depend only on interfaces, enabling independent evolution, runtime flexibility, and easier testing.
•"Favor" means prefer, not mandate — Composition should be your default; inheritance should require justification.
•Black-box over white-box — Prefer hiding implementation (composition) over exposing it (inheritance).
•Design for change — Composition better handles unknown future requirements because it enables recombination without restructuring.
•Industry-validated — Modern languages and frameworks increasingly embrace composition, reflecting decades of lessons learned.

What's Next:

Now that we understand the principle's origins and philosophy, the next page explores why composition is often preferred in detail—examining the specific advantages that make it the superior choice for most design decisions.

Page Complete

You now understand the foundational principle of "Favor Composition Over Inheritance"—its historical context, what it actually means, and the philosophy behind it. This principle will inform your design decisions throughout your career. Next, we'll examine the specific reasons why composition is often the better choice.

1 / 4

Loading learning content...

System Design (LLD)Favor Composition Over Inheritance

Favor Composition Over Inheritance — The Critical Design Choice

LevelIntermediate

Duration60 mins

TopicFavor Composition Over Inheritance

1 / 4

The 'Favor Composition Over Inheritance' Principle Explained

The Principle That Shaped Modern Software Design

In the landscape of software design principles, few have had as profound an impact as the maxim: "Favor Composition Over Inheritance."

Understanding this principle deeply is essential. It separates engineers who write rigid, fragile hierarchies from those who craft systems that gracefully adapt to changing requirements.

What You Will Learn

The Historical Context

To understand why "favor composition over inheritance" became a foundational principle, we must first understand the context in which it emerged.

The Early Promise of Inheritance

When object-oriented programming gained mainstream adoption in the 1980s and 1990s, inheritance was celebrated as a revolutionary mechanism for code reuse. The promise was compelling:

Define common behavior in base classes
Specialize through subclasses
Share code effortlessly through the inheritance chain

Early OOP textbooks and courses heavily emphasized inheritance. Class hierarchies became the primary organizational structure. The ability to model "is-a" relationships felt natural and powerful.

The Inheritance Honeymoon Phase

•Academic enthusiasm — Universities taught inheritance as the cornerstone of OOP, often before students encountered real-world complexity.
•Simple examples worked beautifully — The canonical Animal → Dog → Beagle hierarchies were intuitive and clean.
•Code reuse seemed magical — Define once in the parent, use everywhere in children.
•Polymorphism through inheritance — A unified mechanism for achieving type flexibility.
•Framework design centered on inheritance — Early UI frameworks (MFC, early Java AWT) relied heavily on inheritance for extension.

The Reality Check

By the mid-1990s, experienced practitioners had accumulated enough battle scars to articulate what wasn't working. The Gang of Four crystallized this wisdom in a single, powerful recommendation.

The Gang of Four's Original Statement

"Favor object composition over class inheritance."

What the Principle Actually Means

Before diving deeper, let's establish precise definitions. The principle involves two distinct mechanisms for sharing behavior and building complex objects:

Class Inheritance ("White-Box Reuse")

Inheritance creates a subtype relationship where a child class inherits implementation from a parent class. The internals of the parent are visible to the child:

Child classes automatically receive parent behavior
Children can override parent methods
Children have access to protected parent members
The relationship is static—defined at compile time
Children are coupled to the parent's implementation details

Object Composition ("Black-Box Reuse")

Composition creates a "has-a" relationship where one object contains references to other objects and delegates behavior to them:

Objects collaborate by sending messages to contained objects
Behavior is acquired through delegation, not inheritance
The contained objects' internals remain hidden
Relationships can be changed at runtime
Objects are coupled only to interfaces, not implementations

Inheritance vs Composition: Fundamental Comparison
Aspect	Inheritance (White-Box)	Composition (Black-Box)
Relationship	IS-A (type relationship)	HAS-A (ownership/collaboration)
Coupling	High—child knows parent internals	Low—only interface contracts
Binding Time	Compile-time (static)	Runtime (dynamic)
Visibility	Protected/public parent members visible	Only public interface visible
Reuse Mechanism	Inheriting implementation	Delegating to contained objects
Change Impact	Parent changes break children	Internal changes are hidden
Flexibility	Fixed at design time	Can change at runtime

The "Favor" in "Favor Composition"

Critically, the principle says "favor," not "always use." This is a heuristic, not a commandment:

When both approaches could work, prefer composition
Make inheritance the justified exception, not the default
Consider inheritance only when there's a true "is-a" relationship with behavioral substitutability
Use inheritance when you need to participate in a framework that requires it

The principle acknowledges that inheritance has legitimate uses. It simply argues that composition should be your first instinct because it provides superior flexibility in most scenarios.

The Decision Heuristic

The Problems With Inheritance

The Four Deadly Problems of Inheritance

•The Fragile Base Class Problem — Changes to a base class can unexpectedly break subclasses, even when the base class's public interface remains unchanged. The coupling is so tight that internal implementation changes propagate outward.
•The Tight Coupling Problem — Subclasses are intimately tied to their parent's implementation. They depend not just on the interface, but on how the parent implements that interface internally.
•The Rigid Hierarchy Problem — Once established, inheritance hierarchies are difficult to restructure. Adding new variations often requires modifying existing classes or introducing awkward intermediate base classes.
•The Composition Explosion Problem — When you need to combine behaviors from multiple sources, single inheritance languages force you into awkward workarounds, while multiple inheritance creates its own complexity (the diamond problem).

Deep Dive: The Fragile Base Class Problem

Consider a Window base class with a method display() that calls a protected helper method renderBorder(). A subclass FancyWindow overrides renderBorder() to draw a decorative border.

The subclass author and the base class author made reasonable decisions independently. Neither violated any contract. Yet the system broke.

This is the insidious nature of inheritance coupling: you depend on implementation details that aren't part of the public contract, and you often don't know it until something breaks.

fragile-base-class-example
Java
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
// The Fragile Base Class Problem Illustrated
 
// ORIGINAL BASE CLASS (v1.0)
public class Window {
    protected void renderBorder() {
        // Default border rendering
        Graphics.drawRectangle(bounds);
    }
    
    public void display() {
        renderBorder();
        renderContent();
    }
}
 
// SUBCLASS - works fine with v1.0
public class FancyWindow extends Window {
    @Override
    protected void renderBorder() {
        // Custom decorative border
        Graphics.drawDecorativeBorder(bounds);
        playAnimation();
    }
}
 
// BASE CLASS MODIFICATION (v1.1) - "optimization"
public class Window {
    private boolean borderCached = false;
    
    protected void renderBorder() {
        Graphics.drawRectangle(bounds);
    }
    
    public void display() {
        // "Safe" optimization - call renderBorder only once
        if (!borderCached) {
            renderBorder();
            borderCached = true;
        }
        renderContent();
    }
}
 
// PROBLEM: FancyWindow is now broken!
// - Animation plays only once (first display)
// - Resizing doesn't update the decorative border
// - The subclass author made no mistakes
// - The base class author made no mistakes
// - Yet the system is broken due to implicit coupling

The Hidden Contract Problem

The Composition Alternative

Composition solves these problems by fundamentally changing how objects share behavior. Instead of inheriting implementation, objects delegate to collaborators:

Let's reimagine the FancyWindow example using composition:

composition-solution
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
// The Composition Solution
 
// Define a contract for border rendering
public interface BorderRenderer {
    void render(Rectangle bounds);
}
 
// Different border implementations
public class SimpleBorderRenderer implements BorderRenderer {
    @Override
    public void render(Rectangle bounds) {
        Graphics.drawRectangle(bounds);
    }
}
 
public class DecorativeBorderRenderer implements BorderRenderer {
    @Override
    public void render(Rectangle bounds) {
        Graphics.drawDecorativeBorder(bounds);
        playAnimation();
    }
}
 
// Window uses composition instead of inheritance
public class Window {
    private BorderRenderer borderRenderer;
    
    public Window(BorderRenderer borderRenderer) {
        this.borderRenderer = borderRenderer;
    }
    
    public void display() {
        borderRenderer.render(bounds);  // Delegate to component
        renderContent();
    }
    
    // Can even change at runtime!
    public void setBorderRenderer(BorderRenderer renderer) {
        this.borderRenderer = renderer;
    }
}
 
// Usage - Behavior is composed, not inherited
Window fancyWindow = new Window(new DecorativeBorderRenderer());
Window simpleWindow = new Window(new SimpleBorderRenderer());
 
// Runtime flexibility
fancyWindow.setBorderRenderer(new SimpleBorderRenderer());  // Change behavior!

Notice what composition provides:

Explicit Dependencies — The Window class clearly declares it needs a BorderRenderer. No hidden coupling.
Implementation Isolation — How DecorativeBorderRenderer works internally is completely hidden from Window. Changes to the renderer don't affect Window.
Runtime Flexibility — Behavior can be swapped at runtime. The same Window instance can have different renderers at different times.
Easy Testing — Mock or stub the BorderRenderer interface to test Window in isolation.
Independent Evolution — The BorderRenderer implementations can evolve independently of Window.

Inheritance Approach

•Behavior fixed at compile time
•Subclass coupled to parent implementation
•Parent changes may break subclasses
•Testing requires the entire hierarchy
•One inheritance chain per class

Composition Approach

•Behavior changeable at runtime
•Components coupled only to interfaces
•Component internals are encapsulated
•Components can be tested independently
•Unlimited component combinations

The Philosophy Behind the Principle

Understanding the deeper philosophy helps internalize this principle as a way of thinking, not just a rule to follow.

Prefer Black-Box Over White-Box Reuse

The Gang of Four distinguished between "white-box" reuse (inheritance) and "black-box" reuse (composition):

White-box: You see inside the box (parent class internals visible to subclasses)
Black-box: You interact only with the surface (interface contracts)

Black-box reuse is more robust because it limits your dependencies to the surface. You don't know—and don't need to know—what's inside the box. This ignorance is protective.

The Information Hiding Principle Connection

Design for Change

The fundamental assumption behind "favor composition" is that requirements change. Software that cannot adapt is software that will eventually be replaced.

Inheritance hierarchies optimize for the current understanding of the domain. Composition optimizes for unknown future changes. Given that we cannot predict the future, composition is the safer bet.

Aggregate, Don't Inherit

Rather than thinking "X is a Y," train yourself to think "X has a Y" or "X uses a Y":

Instead of SportsCar extends Car → Car has an Engine (or PerformanceEngine)
Instead of Manager extends Employee → Employee has a Role (possibly ManagerRole)
Instead of FileLogger extends Logger → Logger uses a LogDestination (could be FileDestination)

This mental shift opens up flexibility: an Employee can change roles, a Car can have its engine upgraded, a Logger can switch destinations at runtime.

Thinking Inheritance vs Thinking Composition
Inheritance Thinking	Composition Thinking
"X is a specialized Y"	"X uses Y's capabilities"
"Define a subtype"	"Assemble from parts"
"Override parent behavior"	"Delegate to collaborators"
"Extend the hierarchy"	"Add a new component type"
"This class IS an animal"	"This object HAS movement behavior"

Industry Validation

This isn't just theoretical—the principle has been validated across decades of industry practice:

Framework Evolution

Compare the design of early vs modern frameworks:

Early frameworks (1990s) — Required extensive inheritance. To use the framework, you extended their base classes (Template Method pattern everywhere).
Modern frameworks (2010s–present) — Prefer composition, dependency injection, and interfaces. You provide implementations of small interfaces that the framework orchestrates.

This evolution reflects hard-learned lessons about maintainability.

Modern Design Approach Examples

•Go's composition model — Go famously has no inheritance at all. All code reuse is through composition and interfaces. This was a deliberate design choice based on the principle.
•Rust's trait system — Rust uses traits (interface-like contracts) and composition. There's no class inheritance hierarchy.
•React's component model — React moved from class inheritance (React.Component) to function components with hooks—a pure composition model.
•Microservices architecture — Services compose to form systems. No service "inherits" from another; they collaborate through APIs.
•Entity-Component-System (ECS) — Modern game engines use ECS, which is pure composition. Entities have components; there's no entity inheritance.

What the Experts Say

Beyond the Gang of Four, numerous authoritative voices have reinforced this principle:

"Inheritance is a powerful way to achieve code reuse, but it is not always the best tool for the job. Used inappropriately, it leads to fragile software." — Joshua Bloch, Effective Java

"The problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle." — Joe Armstrong, Creator of Erlang

"Prefer composition over inheritance. It's more flexible and avoids the fragile base class problem." — Robert C. Martin (Uncle Bob)

A Principle That Transcends Languages

Common Misconceptions

The principle is frequently misunderstood. Let's clarify what it does not mean:

What the Principle Does NOT Mean

•"Never use inheritance" — Inheritance has valid uses. The principle says favor composition when both approaches could work. Some situations genuinely call for inheritance.
•"Inheritance is bad" — Inheritance is a legitimate language feature. It's the default, reflexive use of inheritance that causes problems.
•"Always add an interface between everything" — Over-abstraction is its own problem. The principle guides toward flexibility, not unnecessary complexity.
•"Composition means more code" — While composition may require more explicit wiring, this explicitness often reduces bugs and makes the code more maintainable.
•"This only applies to class design" — The principle's philosophy (prefer smaller, recombinable units over rigid hierarchies) applies to modules, services, and systems—not just classes.

The Balance Point

When Inheritance IS Appropriate

Despite favoring composition, inheritance remains appropriate when:

True is-a relationships with behavioral compatibility — When the subtype genuinely is substitutable for the parent in all contexts (Liskov Substitution Principle).
Framework extension points designed for inheritance — When the framework expects you to extend a class and override specific methods (Template Method pattern).
Immutable value hierarchies — Inheritance works well for immutable value types where behavior won't change dynamically.
Closed hierarchies — When you control all descendants and the hierarchy is stable and unlikely to change.

These cases are the exception, not the default. The burden of proof should be on inheritance.

Summary: The Foundational Principle

We've established the core understanding of "Favor Composition Over Inheritance." Let's consolidate the key points:

Key Takeaways

•Historical origin — The principle emerged from the Gang of Four's distillation of industry wisdom about the problems with inheritance-heavy designs.
•Inheritance creates tight coupling — Subclasses depend on parent implementation details, creating the fragile base class problem and rigid hierarchies.
•Composition provides loose coupling — Objects depend only on interfaces, enabling independent evolution, runtime flexibility, and easier testing.
•"Favor" means prefer, not mandate — Composition should be your default; inheritance should require justification.
•Black-box over white-box — Prefer hiding implementation (composition) over exposing it (inheritance).
•Design for change — Composition better handles unknown future requirements because it enables recombination without restructuring.
•Industry-validated — Modern languages and frameworks increasingly embrace composition, reflecting decades of lessons learned.

What's Next:

Page Complete

1 / 4