When to Use Which - Learning Module

Loading content...

0/246

Decision Framework

Beyond Rules of Thumb

Every experienced software engineer has faced this pivotal moment: staring at a design problem, knowing that both inheritance and composition could solve it, but uncertain which choice will serve the system well as it evolves. The decision feels consequential because it is—the wrong choice creates technical debt that compounds over years.\n\nYet too often, this decision is made based on incomplete heuristics: "Favor composition"—yes, but when is inheritance actually the better choice? "Use inheritance for is-a relationships"—but the is-a test alone is insufficient, as countless Rectangle-Square debacles have demonstrated.\n\nWhat we need isn't another simplistic rule. We need a systematic decision framework—a structured approach that considers multiple dimensions of the design problem and guides us toward the choice that best serves our actual requirements.

What You Will Learn

By the end of this page, you will possess a comprehensive decision framework for choosing between inheritance and composition. You'll understand the key questions to ask, the dimensions to evaluate, and how to weigh competing concerns. This framework transforms an often uncertain decision into an informed, defensible one.

Why a Framework Is Necessary

Before presenting the framework, let's understand why simple rules fail us in practice.\n\nThe Inadequacy of Simple Heuristics\n\nConsider the most common guidance:\n\n- "Favor composition over inheritance" — This tells us to prefer composition, but offers no guidance on when inheritance is actually appropriate. Taken literally, we'd never use inheritance, which ignores its legitimate uses.\n\n- "Use inheritance for is-a relationships" — This is a necessary but insufficient condition. A Square mathematically is-a Rectangle, yet the famous example demonstrates that inheritance here violates behavioral substitutability.\n\n- "Use composition for has-a relationships" — While helpful, this doesn't address the many cases where the relationship is ambiguous, or where a design could be modeled either way.

Why Simple Rules Fail

•Context blindness — Simple rules ignore the specific constraints and requirements of your particular design problem.
•Binary thinking — Real designs often need nuanced combinations of both approaches, not an either/or choice.
•Temporal myopia — Rules don't account for how requirements and understanding will evolve over time.
•Trade-off ignorance — Every design choice involves trade-offs; rules don't help you weigh competing concerns.
•Domain variance — The "right" choice varies significantly across different domains, team sizes, and system lifespans.

The Need for Dimensional Analysis\n\nEffective decision-making requires analyzing the problem across multiple dimensions simultaneously:\n\n- What is the fundamental nature of the relationship between the types?\n- What degree of flexibility will the design require over its lifetime?\n- What are the coupling implications of each approach in this context?\n- How does the choice affect testability and maintainability?\n- What do the framework and ecosystem constraints dictate?\n- What is the team's experience and the organization's conventions?\n\nA framework organizes these considerations into a coherent decision process.

Frameworks Enable Judgment, Not Replace It

The goal of a decision framework is not to mechanically produce answers but to structure your thinking. It ensures you consider relevant factors systematically rather than overlooking crucial dimensions. The final judgment remains yours—the framework just makes that judgment better informed.

The Decision Framework Overview

The decision framework consists of five key dimensions that you evaluate for each design choice. Each dimension contributes evidence toward either inheritance or composition, and the overall pattern of evidence guides your decision.\n\nThe Five Dimensions:\n\n1. Relationship Analysis — Is this truly an is-a relationship with behavioral substitutability?\n2. Flexibility Requirements — How much will the behavior need to change over time?\n3. Coupling Assessment — What are the coupling implications in this specific context?\n4. Constraint Evaluation — What do frameworks, languages, and ecosystems require?\n5. Practical Considerations — What do team capabilities and organizational context suggest?

Converting Mermaid diagram...

Framework Application Process:\n\n1. Evaluate each dimension — For each dimension, assess whether the evidence points toward inheritance, composition, or is neutral.\n\n2. Note dimension strength — Some dimensions may provide strong signals, others weak. A dimension that provides a strong signal carries more weight.\n\n3. Look for patterns — If most dimensions point the same direction, the choice is clear. If signals conflict, deeper analysis is needed.\n\n4. Consider hybrid approaches — When signals are mixed, a combination of inheritance and composition may be optimal.\n\n5. Document your reasoning — The framework provides vocabulary to explain and defend your design decisions.\n\nLet's examine each dimension in depth.

Dimension 1: Relationship Analysis

The first and most fundamental dimension examines the nature of the relationship between types. This goes beyond the simple "is-a" test to consider behavioral substitutability and domain semantics.\n\nThe Enhanced Is-A Test\n\nThe traditional is-a test asks: "Is a B always an A?"\n\nThe enhanced is-a test adds: "Can a B always substitute for an A in all behavioral contexts, satisfying all client expectations?"\n\nThis addition is crucial. It's the difference between mathematical categorization and behavioral compatibility.

Enhanced Is-A Test Questions
Question	What You're Assessing
Is a B conceptually a kind of A?	Domain relationship — does the language make sense?
Can B substitute for A everywhere A is expected?	Behavioral compatibility — Liskov Substitution Principle
Does B maintain all invariants that clients of A expect?	Contract preservation — no surprises for clients
If A changes its interface, should B also change?	Coupling appropriateness — should they evolve together?
Is the inheritance relationship stable over time?	Temporal stability — will this remain true?

Signals Toward Inheritance:\n\n- All enhanced is-a questions are answered "yes"\n- The relationship is deeply rooted in the domain, not an implementation convenience\n- The subtype specializes behavior within the contracts of the supertype\n- The hierarchy is stable and unlikely to require restructuring\n\nSignals Toward Composition:\n\n- The is-a relationship exists but behavioral substitutability is questionable\n- The relationship feels like an implementation shortcut rather than domain truth\n- The "subtype" would violate expectations if used polymorphically\n- Multiple possible categorizations exist (a thing could belong to multiple hierarchies)\n- The relationship might change or become more nuanced over time

relationship-analysis-examples
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
50
51
52
53
54
55
// Example: Relationship Analysis in Practice
 
// STRONG IS-A RELATIONSHIP — Inheritance may be appropriate
// A CheckingAccount IS-A BankAccount
// - All BankAccount operations make sense for CheckingAccount
// - Clients expecting BankAccount can use CheckingAccount safely
// - The relationship is stable and domain-grounded
public class CheckingAccount extends BankAccount {
    private double overdraftLimit;
    
    @Override
    public void withdraw(double amount) {
        // Specializes but maintains the contract
        if (balance + overdraftLimit >= amount) {
            balance -= amount;
        }
    }
}
 
// WEAK IS-A RELATIONSHIP — Composition is likely better
// Does a Square IS-A Rectangle? Mathematically yes, but behaviorally?
// - Rectangle clients expect independent width/height modification
// - Square cannot satisfy this expectation
// - The "is-a" creates behavioral surprises
 
// BAD: Inheritance violates LSP
public class Square extends Rectangle {
    @Override
    public void setWidth(int width) {
        this.width = width;
        this.height = width;  // Surprise! Side effect violates Rectangle contract
    }
}
 
// GOOD: Composition allows proper modeling
public class Square {
    private int side;
    
    public Rectangle asRectangle() {
        return new Rectangle(side, side);  // Explicit conversion
    }
}
 
// AMBIGUOUS RELATIONSHIP — Analyze deeper
// Is an Employee a Person? Is a Manager an Employee?
// The answer depends on your domain needs:
// - If you need polymorphic treatment: consider inheritance
// - If roles change over time: composition is better
 
// Composition allows role changes
public class Employee {
    private Person person;           // HAS-A person
    private Role currentRole;        // HAS-A role (can change)
    private Department department;   // HAS-A department (can change)
}

The Temporal Dimension of Relationships

Relationships that seem permanent today may become fluid tomorrow. A 'Product IS-A DigitalProduct' might seem stable until physical products are introduced. Always ask: 'In what ways might this relationship evolve?' If change is plausible, composition provides an escape hatch that inheritance does not.

Dimension 2: Flexibility Requirements

The second dimension assesses how much flexibility the design will need over its lifetime. This is perhaps the dimension where composition most often wins, because it provides fundamentally more flexibility.\n\nTypes of Flexibility:\n\n- Behavioral flexibility — Can behavior be changed, extended, or configured?\n- Structural flexibility — Can the relationship structure be modified?\n- Temporal flexibility — Can things change at runtime, not just compile time?\n- Combinatorial flexibility — Can different behaviors be combined in different ways?

Inheritance Flexibility

•Behavior fixed at compile time
•Class identity permanent for object lifetime
•Extension requires new subclasses
•Combinations require hierarchy explosion
•Runtime behavior switching impossible

Composition Flexibility

•Behavior configurable at runtime
•Component relationships can change
•Extension via new component implementations
•Combinations via component assembly
•Behavior switching through delegation

Key Flexibility Questions:\n\n1. Will behavior need to change at runtime?\n - If yes: Strong signal toward composition\n - If no: Neutral\n\n2. Will there be many behavior combinations?\n - If yes: Composition avoids combinatorial explosion\n - If few, stable combinations: Inheritance may suffice\n\n3. How often will requirements change?\n - Frequent changes: Composition adapts more easily\n - Stable, well-understood domain: Inheritance is less risky\n\n4. Is the variation axis well-understood?\n - If you know exactly what varies: Either approach can work\n - If variation is uncertain: Composition provides more options

flexibility-analysis
TypeScript
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
73
74
75
// Flexibility Analysis Examples
 
// SCENARIO 1: Low flexibility needs
// A logging level hierarchy has fixed, well-known variations
// Inheritance is reasonable here
enum LogLevel { DEBUG, INFO, WARN, ERROR }
 
abstract class Logger {
    abstract log(level: LogLevel, message: string): void;
}
 
class ConsoleLogger extends Logger { /* ... */ }
class FileLogger extends Logger { /* ... */ }
 
 
// SCENARIO 2: High combinatorial flexibility needed
// A document can be formatted, encrypted, and compressed
// With inheritance, you'd need:
// - FormattedDocument, EncryptedDocument, CompressedDocument
// - FormattedEncryptedDocument, FormattedCompressedDocument
// - EncryptedCompressedDocument, FormattedEncryptedCompressedDocument
// That's 2^n classes for n features!
 
// With composition, you compose decorators:
interface Document {
    getContent(): string;
}
 
class BaseDocument implements Document {
    constructor(private content: string) {}
    getContent() { return this.content; }
}
 
class FormattedDocument implements Document {
    constructor(private wrapped: Document) {}
    getContent() { return format(this.wrapped.getContent()); }
}
 
class EncryptedDocument implements Document {
    constructor(private wrapped: Document) {}
    getContent() { return encrypt(this.wrapped.getContent()); }
}
 
// Compose any combination:
const doc = new FormattedDocument(
    new EncryptedDocument(
        new BaseDocument("Hello")
    )
);
 
 
// SCENARIO 3: Runtime behavior switching needed
// A payment processor needs to switch providers based on context
// Composition enables runtime switching; inheritance cannot
 
interface PaymentProvider {
    processPayment(amount: number): Promise<PaymentResult>;
}
 
class PaymentProcessor {
    private provider: PaymentProvider;
    
    setProvider(provider: PaymentProvider) {
        this.provider = provider;  // Runtime switching!
    }
    
    async process(amount: number) {
        return this.provider.processPayment(amount);
    }
}
 
// Switch providers at runtime based on conditions
processor.setProvider(
    amount > 10000 ? new HighValueProvider() : new StandardProvider()
);

The Combinatorial Explosion Problem

When you have N independent dimensions of variation, inheritance requires up to 2^N classes to cover all combinations. This 'class explosion' is a powerful signal toward composition, which handles the same variations with N component types that can be freely combined.

Dimension 3: Coupling Assessment

The third dimension examines the coupling implications of each approach in your specific context. While inheritance generally creates tighter coupling, the acceptability of that coupling depends on your design goals.\n\nUnderstanding Coupling Depth:\n\nInheritance and composition create different types of coupling:\n\n- Inheritance coupling — Subclass is coupled to parent's implementation, including protected members, method call patterns, and internal state assumptions.\n\n- Composition coupling — Client is coupled only to the component's interface. Implementation details are hidden.

Coupling Comparison by Aspect
Coupling Aspect	Inheritance	Composition
Interface coupling	Yes — must match parent interface	Yes — must match component interface
Implementation coupling	Yes — depends on how parent works	No — hidden behind interface
Change propagation	High — parent changes may break children	Low — internal changes are hidden
Compile-time dependency	Strong — child cannot exist without parent	Weaker — can use interfaces
Testing isolation	Hard — requires parent or hierarchy	Easy — can mock components

When Tight Coupling Is Acceptable:\n\nInheritance's tight coupling is acceptable when:\n\n1. The parent is stable and unlikely to change — If you control the parent and can guarantee stability, the coupling risk is low.\n\n2. The coupling is intentional and desired — Sometimes you want children to be tightly coupled to the parent (e.g., framework extension points).\n\n3. The hierarchy is small and cohesive — A shallow hierarchy with few subclasses is more manageable.\n\n4. The domain demands it — Some domain models genuinely require type hierarchies for proper expression.\n\nWhen Tight Coupling Is Problematic:\n\n1. The parent is external or unstable — If you don't control the parent, changes can break your code without warning.\n\n2. Multiple teams work on the hierarchy — Coordination becomes increasingly difficult.\n\n3. The component will be reused broadly — Tight coupling makes reuse in different contexts difficult.\n\n4. Testing is a priority — High coupling makes isolated testing nearly impossible.

coupling-assessment
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
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
// Coupling Assessment Examples
 
// ACCEPTABLE COUPLING: You own both classes, they evolve together
// This is a closed, cohesive hierarchy within your control
 
public abstract class AbstractValidator {
    protected final List<ValidationRule> rules;
    
    protected AbstractValidator() {
        this.rules = initializeRules();
    }
    
    protected abstract List<ValidationRule> initializeRules();
    
    public final ValidationResult validate(Object target) {
        for (ValidationRule rule : rules) {
            if (!rule.isValid(target)) {
                return ValidationResult.failure(rule.getMessage());
            }
        }
        return ValidationResult.success();
    }
}
 
// Subclass IS tightly coupled to AbstractValidator's implementation
// But this is acceptable because:
// - You control AbstractValidator
// - The pattern is well-documented (Template Method)
// - Changes will be coordinated
public class EmailValidator extends AbstractValidator {
    @Override
    protected List<ValidationRule> initializeRules() {
        return List.of(
            new NotNullRule(),
            new EmailFormatRule()
        );
    }
}
 
 
// PROBLEMATIC COUPLING: Inheriting from external/unstable class
 
// BAD: Inheriting from a framework class you don't control
public class MySpecialArrayList extends ArrayList<String> {
    private int addCount = 0;
    
    @Override
    public boolean add(String element) {
        addCount++;
        return super.add(element);
    }
    
    @Override
    public boolean addAll(Collection<? extends String> c) {
        addCount += c.size();
        return super.addAll(c);  // Does ArrayList.addAll call add()? Depends on version!
    }
    
    public int getAddCount() {
        return addCount;  // May be wrong due to internal implementation dependencies
    }
}
 
// GOOD: Composition avoids the fragile base class problem
public class CountingList<T> {
    private final List<T> delegate = new ArrayList<>();
    private int addCount = 0;
    
    public boolean add(T element) {
        addCount++;
        return delegate.add(element);
    }
    
    public boolean addAll(Collection<? extends T> c) {
        addCount += c.size();
        return delegate.addAll(c);  // No implementation dependency!
    }
    
    public int getAddCount() {
        return addCount;  // Always correct
    }
    
    // Delegate other methods as needed
}

The 'Control' Heuristic

A useful heuristic: Inheritance from classes you control is far less risky than inheritance from classes you don't. If you don't own and can't modify the parent class, strongly prefer composition to insulate yourself from uncontrollable changes.

Dimension 4: Constraint Evaluation

The fourth dimension considers external constraints that may influence or dictate your choice. These are factors outside the pure design realm that nonetheless shape what's practical.\n\nTypes of Constraints:\n\n1. Language constraints — What does your programming language allow or encourage?\n2. Framework constraints — What does the framework you're using require?\n3. Library constraints — What patterns do the libraries you depend on expect?\n4. Organizational constraints — What are your team's conventions and capabilities?\n5. Performance constraints — Are there measurable performance implications?

Language-Specific Considerations

•Java — Single inheritance of classes, multiple interface implementation. Abstract classes provide partial implementation. Favors composition for flexibility, inheritance for framework extension points.
•TypeScript/JavaScript — Class inheritance exists, but the dynamic nature favors composition. Mixins provide an alternative pattern. The ecosystem generally prefers composition.
•Python — Multiple inheritance available (with MRO complexity). Both patterns work; duck typing reduces the need for interface hierarchies. Composition is generally preferred.
•Go — No class inheritance at all. Embedding provides limited composition-like behavior. Forces composition thinking by design.
•Rust — No class inheritance. Traits provide polymorphism. Composition is the only option for code reuse across types.
•C++ — Full multiple inheritance with associated complexity. Virtual inheritance addresses diamond problem. Both patterns fully supported.

Framework Requirements:\n\nMany frameworks have strong opinions about inheritance vs composition:\n\n- Servlet API — Expects you to extend HttpServlet. Inheritance is mandatory for the extension point.\n\n- JUnit 3 — Required extending TestCase. This was inheritance-based.\n\n- JUnit 4/5 — Uses annotations and composition. No inheritance required.\n\n- Spring Framework — Historically used abstract base classes; modern Spring strongly favors interface-based composition and dependency injection.\n\n- React — Earlier versions required extending React.Component. Modern React uses function components with hooks—pure composition.\n\nThe Lesson: Framework evolution generally moves from inheritance toward composition, reflecting industry learning.

Constraint-Driven Decision Signals
Constraint Type	Inheritance Signal	Composition Signal
Framework requires class extension	Strong	—
Language lacks inheritance (Go, Rust)	—	Mandatory
Library provides abstract base classes	Moderate	—
Team experienced with composition patterns	—	Moderate
Performance-critical hot path	Evaluate	Evaluate
Must integrate with legacy inheritance hierarchy	Strong	—

Performance Considerations

In most business applications, the performance difference between inheritance and composition is negligible. Virtual method dispatch (inheritance) and interface dispatch (composition) are both highly optimized in modern runtimes. Only in extreme hot paths should performance influence this choice—and even then, measure before deciding.

Dimension 5: Practical Considerations

The final dimension addresses practical, contextual factors that influence what actually works for your team and situation. These "soft" factors often determine success as much as technical considerations.\n\nTeam and Organizational Context:\n\n1. Team familiarity — Is the team more experienced with inheritance or composition patterns? The better-understood approach may succeed where the theoretically superior approach struggles.\n\n2. Codebase consistency — What patterns does the existing codebase use? Consistency has value; mixing approaches without reason creates confusion.\n\n3. Code ownership — Do multiple teams work on related classes? Inheritance creates coordination challenges across team boundaries.\n\n4. Review and onboarding — Which approach will be easier for new team members to understand and for code reviewers to evaluate?

Practical Trade-off Considerations

•Code volume — Composition often requires more explicit code (delegation methods). Inheritance provides automatic method inheritance. For large interfaces, the boilerplate difference is significant.
•Discoverability — Inheritance makes available methods obvious in the type hierarchy. Composition requires examining what's composed. IDE support mitigates but doesn't eliminate this.
•Debugging complexity — Inheritance debugging follows the class hierarchy. Composition debugging follows the delegation chain. Neither is inherently simpler; familiarity matters.
•Refactoring ease — Refactoring from inheritance to composition is generally harder than the reverse. If uncertain, starting with composition gives more options.
•Testing infrastructure — Does your team have strong mocking/stubbing infrastructure? Composition's testing advantages are only realized if the infrastructure exists.

Project Lifecycle Considerations:\n\n- Early-stage projects — You understand the domain poorly. Composition provides more options for change.\n\n- Mature, stable domains — You understand what varies and what doesn't. Inheritance for stable parts is lower risk.\n\n- Throwaway/prototype code — Speed matters more than flexibility. Use whatever is faster to write.\n\n- Long-lived production systems — Maintainability matters most. Composition generally wins for longevity.\n\nThe Right Question:\n\nUltimately, the practical question is: "What will help this team, working on this system, at this stage, succeed?" Technical superiority that the team can't execute doesn't help.

When Uncertain, Prefer Composition

If after analyzing all dimensions the choice remains unclear, defaulting to composition is generally the safer bet. Composition preserves more options for future change, and refactoring from composition to inheritance (if you later determine inheritance is better) is typically easier than the reverse.

Applying the Framework

Let's consolidate the framework into an actionable decision process.\n\nStep-by-Step Application:\n\n1. State the design choice clearly — "Should X inherit from Y or use Y via composition?"\n\n2. Evaluate each dimension — For each of the five dimensions, note whether evidence points toward inheritance, composition, or is neutral.\n\n3. Weight by signal strength — Strong signals count more. A weak signal toward inheritance doesn't override a strong signal toward composition.\n\n4. Look at the overall pattern — Are signals predominantly in one direction? Or mixed?\n\n5. Make the decision — Choose the approach supported by the weight of evidence. If mixed, consider hybrid approaches.\n\n6. Document your reasoning — Record why you made this choice for future reference.

Decision Framework Quick Reference
Dimension	Inheritance Signals	Composition Signals
Relationship	True is-a + behavioral substitutability	Has-a, uses-a, or questionable is-a
Flexibility	Stable variations, no runtime changes	Runtime changes, combinatorial variations
Coupling	You control parent, intentional coupling	External parent, broad reuse, testing priority
Constraints	Framework requires inheritance	Language favors composition
Practical	Team familiar with inheritance patterns	Uncertain domain, long-lived system

What's Next:\n\nNow that you have the overall framework, the following pages dive deep into specific scenarios:\n\n- Page 2: Inheritance-Appropriate Scenarios — When inheritance is genuinely the right choice.\n- Page 3: Composition-Appropriate Scenarios — When composition clearly wins.\n- Page 4: Hybrid Approaches — Combining both techniques effectively.

Page Complete

You now possess a comprehensive framework for deciding between inheritance and composition. This systematic approach considers relationship analysis, flexibility requirements, coupling assessment, constraint evaluation, and practical considerations. Next, we'll explore specific scenarios where inheritance is genuinely appropriate.