Favor Composition - Learning Module

Loading content...

0/246

Why Composition is Often Preferred

Understanding the Advantages of Composition

Having established the historical context and philosophy behind "favor composition over inheritance," we now turn to a rigorous examination of why composition provides advantages that make it the preferred approach in most design scenarios.

This isn't about following rules blindly—it's about understanding the concrete, measurable benefits that composition delivers. By the end of this page, you'll have a complete framework for reasoning about when composition's advantages outweigh the slight additional ceremony it requires.

What You Will Learn

This page examines the six fundamental advantages of composition: loose coupling, encapsulation preservation, enhanced testability, avoiding single inheritance limitations, enabling runtime flexibility, and achieving superior modularity. Each advantage is explored with practical examples and architectural implications.

Advantage 1: Loose Coupling Between Components

Coupling refers to the degree of interdependence between software modules. High coupling means changes in one module are likely to require changes in others. Low coupling means modules can evolve independently.

Why Inheritance Creates Tight Coupling

Inheritance creates one of the tightest forms of coupling in object-oriented programming:

Implementation dependency: Subclasses depend not just on the parent's interface, but on how the parent implements that interface.
Protected member exposure: Subclasses have access to protected members, creating implicit contracts.
Method invocation order: Subclasses may depend on the sequence in which parent methods are called internally.
Behavioral assumptions: Subclasses often assume certain behaviors won't change in the parent.

This coupling is transitive: if class C extends B, and B extends A, then C is coupled to both A and B. Changes to A can break C even though C never directly referenced A.

coupling-comparison
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
// INHERITANCE: Tight Coupling Example
 
public abstract class DataProcessor {
    protected List<String> buffer = new ArrayList<>();
    
    public void process(String data) {
        validate(data);      // Step 1
        transform(data);     // Step 2
        buffer.add(data);    // Step 3
        if (buffer.size() >= 100) {
            flush();         // Step 4
        }
    }
    
    protected abstract void validate(String data);
    protected abstract void transform(String data);
    protected abstract void flush();
}
 
// Subclass is tightly coupled to:
// 1. The buffer field (protected access)
// 2. The processing order (validate → transform → buffer → flush)
// 3. The flush threshold (100)
// 4. The fact that flush() is called automatically
 
public class FileDataProcessor extends DataProcessor {
    @Override
    protected void validate(String data) {
        // Must handle validation as this exact step
    }
    
    @Override
    protected void transform(String data) {
        // Depends on validate() having already run
        // Depends on buffer being accessible
    }
    
    @Override
    protected void flush() {
        // Writes buffer to file
        // Coupled to buffer implementation
    }
}
 
// If parent changes buffer type to Queue, child breaks
// If parent changes processing order, child breaks
// If parent changes flush threshold, child behavior changes

How Composition Achieves Loose Coupling

Composition limits coupling to interface contracts. The containing object knows nothing about how the component implements the interface—only that it fulfills the contract:

loose-coupling-composition
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
// COMPOSITION: Loose Coupling Example
 
// Define focused interfaces (contracts)
public interface DataValidator {
    ValidationResult validate(String data);
}
 
public interface DataTransformer {
    String transform(String data);
}
 
public interface DataSink {
    void write(String data);
    void flush();
}
 
// Compose the processing pipeline
public class DataProcessor {
    private final DataValidator validator;
    private final DataTransformer transformer;
    private final DataSink sink;
    private final int flushThreshold;
    
    public DataProcessor(
        DataValidator validator,
        DataTransformer transformer,
        DataSink sink,
        int flushThreshold  // Configurable!
    ) {
        this.validator = validator;
        this.transformer = transformer;
        this.sink = sink;
        this.flushThreshold = flushThreshold;
    }
    
    public void process(String data) {
        ValidationResult result = validator.validate(data);
        if (!result.isValid()) {
            throw new ValidationException(result.errors());
        }
        String transformed = transformer.transform(data);
        sink.write(transformed);
    }
}
 
// Each component is:
// - Independently implementable
// - Independently testable
// - Independently replaceable
// - Coupled ONLY to its interface contract
 
public class FileDataSink implements DataSink {
    private final List<String> buffer = new ArrayList<>();
    private final File outputFile;
    
    // Internal implementation is COMPLETELY HIDDEN
    // DataProcessor knows nothing about buffers or files
}

Coupling in Inheritance vs Composition
Coupling Dimension	Inheritance	Composition
Interface coupling	Yes—coupled to parent interface	Yes—coupled to component interface
Implementation coupling	Yes—knows HOW parent works	No—only knows WHAT interface promises
Field coupling	Yes—accesses protected fields	No—fields are encapsulated
Method order coupling	Yes—depends on call sequence	No—each call is independent
Transitive coupling	Yes—coupled to entire hierarchy	No—only direct dependencies
Binary coupling	Very high—ABI compatibility	Lower—interface contracts

The Coupling Litmus Test

Ask: "If I change the internal implementation of X, could it break Y?" With inheritance, the answer is often yes due to white-box coupling. With composition, if your interface contract is stable, the answer should be no.

Advantage 2: Encapsulation Preservation

Encapsulation is the bundling of data with the methods that operate on that data, while restricting direct access to the object's internal state. It's fundamental to managing complexity in software.

Inheritance Breaks Encapsulation

The Gang of Four explicitly stated: "Inheritance exposes a subclass to details of its parent's implementation."

This exposure manifests in several ways:

Protected members are implementation details exposed to children: When you mark something protected, you're saying "my children need to know this." But this creates commitments—you can't easily change protected members without breaking subclasses.
Method overriding requires understanding parent behavior: To correctly override a method, you must understand what the parent method does, when it's called, and what invariants it maintains. This knowledge couples you to the implementation.
Self-use patterns create hidden contracts: When a parent method calls another overridable method on this, subclasses must understand this to avoid breaking functionality.

encapsulation-breaking
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
// Classic example: HashSet breaks encapsulation
// This is from Joshua Bloch's "Effective Java"
 
public class InstrumentedHashSet<E> extends HashSet<E> {
    private int addCount = 0;
    
    @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);  // PROBLEM!
    }
    
    public int getAddCount() {
        return addCount;
    }
}
 
// Usage:
InstrumentedHashSet<String> s = new InstrumentedHashSet<>();
s.addAll(Arrays.asList("A", "B", "C"));
System.out.println(s.getAddCount());  // Expected: 3, Actual: 6!
 
// WHY? HashSet.addAll() internally calls add() for each element
// Our overridden add() increments count
// Our addAll() also increments count
// We counted each element TWICE!
 
// This is an ENCAPSULATION VIOLATION:
// The subclass MUST know that HashSet.addAll() calls add()
// This is an implementation detail, not part of the contract
// If HashSet changes this, our subclass breaks

Composition Preserves Encapsulation

With composition, the internal state and implementation of each component remain hidden. Components interact only through their public interfaces:

encapsulation-preserved
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
// Composition solution: Wrapper pattern (from Effective Java)
 
public class InstrumentedSet<E> implements Set<E> {
    private final Set<E> delegate;  // COMPOSITION
    private int addCount = 0;
    
    public InstrumentedSet(Set<E> delegate) {
        this.delegate = delegate;
    }
    
    @Override
    public boolean add(E e) {
        addCount++;
        return delegate.add(e);  // Delegate, don't inherit
    }
    
    @Override
    public boolean addAll(Collection<? extends E> c) {
        addCount += c.size();
        return delegate.addAll(c);  // Delegate to the wrapped set
    }
    
    public int getAddCount() {
        return addCount;
    }
    
    // Delegate all other Set methods to the wrapped set
    @Override
    public int size() { return delegate.size(); }
    @Override
    public boolean isEmpty() { return delegate.isEmpty(); }
    @Override
    public boolean contains(Object o) { return delegate.contains(o); }
    // ... etc
}
 
// Usage:
Set<String> s = new InstrumentedSet<>(new HashSet<>());
s.addAll(Arrays.asList("A", "B", "C"));
System.out.println(((InstrumentedSet<String>) s).getAddCount());  // 3!
 
// WHY IT WORKS:
// - We don't know or care how HashSet.addAll() is implemented
// - We delegate to it and handle our own counting separately
// - If HashSet changes, our code still works
// - Encapsulation is PRESERVED

The Wrapper Trade-off

The composition approach requires delegating all interface methods. This is more code, but consider: you write it once and it's correct forever. The inheritance approach is less code but has a subtle bug that's difficult to understand. More explicit code that's correct beats less code that's wrong.

How Composition Protects Encapsulation

•No access to protected members — Components only expose their public interface.
•No self-use knowledge required — You call methods, but don't need to know if they call each other.
•Implementation changes are invisible — As long as the interface contract holds, internal changes don't affect you.
•Clear boundaries — Each component's encapsulation boundary is the interface, not an implicit shared understanding.

Advantage 3: Enhanced Testability

Testability refers to how easily you can write automated tests for your code. Composition dramatically improves testability by enabling isolation, mocking, and focused test scope.

The Inheritance Testing Challenge

Testing inherited classes is inherently difficult:

You can't test the subclass in isolation: The subclass behavior depends on the parent, so you're always testing the combined behavior.
You can't easily mock the parent: The parent isn't injected—it's hardcoded via the extends keyword.
Parent changes affect subclass tests: When the parent changes, all subclass tests might fail or produce different results.
Testing requires understanding the hierarchy: To write meaningful tests, you must understand what the parent does and how the child interacts with it.
Abstract classes require concrete implementations: You can't instantiate the abstract parent, so you test through children—which conflates parent and child behavior.

testing-inheritance
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
// INHERITANCE: Testing Challenges
 
public abstract class NotificationService {
    protected final MessageQueue queue;  // Dependency
    protected final Logger logger;
    
    public NotificationService(MessageQueue queue, Logger logger) {
        this.queue = queue;
        this.logger = logger;
    }
    
    public void notify(User user, String message) {
        validate(user, message);      // Template step 1
        String formatted = format(message);  // Template step 2
        send(user, formatted);        // Template step 3
        logger.info("Notification sent to " + user.getId());
    }
    
    protected void validate(User user, String message) {
        if (user == null) throw new IllegalArgumentException("User required");
        if (message == null || message.isEmpty()) throw new IllegalArgumentException("Message required");
    }
    
    protected abstract String format(String message);
    protected abstract void send(User user, String message);
}
 
public class EmailNotificationService extends NotificationService {
    @Override
    protected String format(String message) {
        return "<html><body>" + message + "</body></html>";
    }
    
    @Override
    protected void send(User user, String message) {
        // Send email...
    }
}
 
// TESTING PROBLEM:
// To test EmailNotificationService.format(), you must:
// 1. Create the whole object (need queue and logger)
// 2. Either call notify() which runs ALL steps, or
// 3. Use reflection to access protected format() method
 
@Test
void testFormat() {
    // Need to create mocks for dependencies we don't even use
    MessageQueue mockQueue = mock(MessageQueue.class);
    Logger mockLogger = mock(Logger.class);
    
    EmailNotificationService service = new EmailNotificationService(mockQueue, mockLogger);
    
    // Can't easily test format() in isolation!
    // It's protected, called through notify()
}

Composition Enables True Isolation Testing

With composition, each component can be tested independently. Dependencies are injected, making mocking trivial:

testing-composition
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
85
86
87
// COMPOSITION: Easy Testing
 
// Each responsibility is a separate, testable component
public interface MessageFormatter {
    String format(String message);
}
 
public interface MessageSender {
    void send(User user, String message);
}
 
public interface MessageValidator {
    ValidationResult validate(User user, String message);
}
 
// The service composes these components
public class NotificationService {
    private final MessageValidator validator;
    private final MessageFormatter formatter;
    private final MessageSender sender;
    private final Logger logger;
    
    // Dependencies are injected - easy to mock!
    public NotificationService(
        MessageValidator validator,
        MessageFormatter formatter,
        MessageSender sender,
        Logger logger
    ) {
        this.validator = validator;
        this.formatter = formatter;
        this.sender = sender;
        this.logger = logger;
    }
    
    public void notify(User user, String message) {
        ValidationResult result = validator.validate(user, message);
        if (!result.isValid()) throw new ValidationException(result);
        
        String formatted = formatter.format(message);
        sender.send(user, formatted);
        logger.info("Notification sent to " + user.getId());
    }
}
 
// TESTING: Each component is independently testable!
 
// Test the formatter in COMPLETE ISOLATION
public class HtmlMessageFormatterTest {
    @Test
    void testFormat() {
        HtmlMessageFormatter formatter = new HtmlMessageFormatter();
        
        String result = formatter.format("Hello");
        
        assertEquals("<html><body>Hello</body></html>", result);
        // No mocks needed! No other components involved!
    }
}
 
// Test the service with mocked components
public class NotificationServiceTest {
    @Test
    void testNotify_ValidInput_CallsAllComponents() {
        // Arrange - easy mocking
        MessageValidator validator = mock(MessageValidator.class);
        MessageFormatter formatter = mock(MessageFormatter.class);
        MessageSender sender = mock(MessageSender.class);
        Logger logger = mock(Logger.class);
        
        when(validator.validate(any(), any())).thenReturn(ValidationResult.valid());
        when(formatter.format("hello")).thenReturn("<p>hello</p>");
        
        NotificationService service = new NotificationService(
            validator, formatter, sender, logger
        );
        
        // Act
        service.notify(testUser, "hello");
        
        // Assert - verify the orchestration
        verify(validator).validate(testUser, "hello");
        verify(formatter).format("hello");
        verify(sender).send(testUser, "<p>hello</p>");
        verify(logger).info(anyString());
    }
}

Testability: Inheritance vs Composition
Testing Aspect	Inheritance	Composition
Unit isolation	Difficult—tests parent + child together	Easy—test each component alone
Mocking parents	Impossible—can't inject parent	Trivial—inject mocked components
Test scope	Broad—entire hierarchy	Focused—single component
Test brittleness	High—parent changes break child tests	Low—interface contracts stable
Test setup	Complex—need valid hierarchy	Simple—construct component directly
Behavior verification	Implicit—via side effects	Explicit—mock verification

The Testability Heuristic

If you find yourself needing complex test setup, reflection to access protected members, or partial mocking, consider whether composition would simplify things. Well-designed composed systems have straightforward, isolated tests.

Advantage 4: Avoiding Single Inheritance Limitations

Most mainstream OOP languages (Java, C#, Swift, PHP, TypeScript class inheritance) enforce single inheritance: a class can extend only one parent class. This design decision, while avoiding the diamond problem of multiple inheritance, creates significant constraints.

The Single Inheritance Bottleneck

Single inheritance forces difficult choices:

You only get one "is-a" slot: If your class needs to be both Serializable (for persistence) and Comparable (for sorting), you can't inherit from two classes that provide these.
Hierarchies become contorted: To share behavior, you might create artificial intermediate classes that don't represent real domain concepts.
God classes emerge: When you can't spread behavior across multiple parents, classes accumulate responsibilities.
The "inheritance resource" is precious: Like a single parking spot, your one inheritance slot becomes a contested resource—you must choose which single parent is most important.

single-inheritance-problem
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
// SINGLE INHERITANCE: The Limitation Problem
 
// Suppose we have these useful base classes:
public abstract class Observable {
    private List<Observer> observers = new ArrayList<>();
    
    public void addObserver(Observer o) { observers.add(o); }
    public void notifyObservers() { 
        observers.forEach(Observer::update); 
    }
}
 
public abstract class Serializable {
    public abstract byte[] serialize();
    public abstract void deserialize(byte[] data);
}
 
public abstract class Auditable {
    private Instant createdAt;
    private Instant modifiedAt;
    private String modifiedBy;
    
    public void trackModification(String user) { ... }
    public AuditLog getAuditLog() { ... }
}
 
// NOW: We want a User class that is:
// - Observable (for UI updates when user changes)
// - Serializable (for persistence)
// - Auditable (for compliance tracking)
 
// PROBLEM: We can only extend ONE of these!
public class User extends Observable {  // We chose Observable
    // But now we can't use Serializable or Auditable behavior!
    // We must manually implement those features
    // No code reuse, no polymorphism benefits
}
 
// WORKAROUND ATTEMPTS:
 
// Option 1: Deep hierarchy (BAD)
// Observable → SerializableObservable → AuditableSerializableObservable → User
// This is ridiculous and inflexible
 
// Option 2: Copy-paste the code (BAD)
// Duplicate Serializable and Auditable code into User
// No reuse, maintenance nightmare
 
// Option 3: Single inheritance is insufficient
// We need composition!

Composition Provides Unlimited Behavior Combination

With composition, there's no limit to how many behaviors you can combine. You assemble capabilities by including the components you need:

composition-unlimited-behaviors
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
85
86
87
88
89
90
91
92
93
// COMPOSITION: Unlimited Behavior Combination
 
// Define behaviors as interfaces + components
public interface Observable {
    void addObserver(Observer o);
    void removeObserver(Observer o);
    void notifyObservers();
}
 
public class ObserverSupport implements Observable {
    private List<Observer> observers = new ArrayList<>();
    
    @Override
    public void addObserver(Observer o) { observers.add(o); }
    @Override
    public void removeObserver(Observer o) { observers.remove(o); }
    @Override
    public void notifyObservers() {
        observers.forEach(Observer::update);
    }
}
 
public interface Serializable {
    byte[] serialize();
    void deserialize(byte[] data);
}
 
public interface Auditable {
    void trackModification(String user);
    AuditLog getAuditLog();
}
 
public class AuditSupport implements Auditable {
    private List<AuditEntry> entries = new ArrayList<>();
    
    @Override
    public void trackModification(String user) {
        entries.add(new AuditEntry(Instant.now(), user));
    }
    
    @Override
    public AuditLog getAuditLog() {
        return new AuditLog(entries);
    }
}
 
// NOW: User can have ALL behaviors through composition!
public class User implements Observable, Serializable, Auditable {
    // Compose the behaviors
    private final ObserverSupport observerSupport = new ObserverSupport();
    private final AuditSupport auditSupport = new AuditSupport();
    
    // User's own state
    private String name;
    private String email;
    
    // Delegate Observable methods
    @Override
    public void addObserver(Observer o) { observerSupport.addObserver(o); }
    @Override
    public void removeObserver(Observer o) { observerSupport.removeObserver(o); }
    @Override
    public void notifyObservers() { observerSupport.notifyObservers(); }
    
    // Delegate Auditable methods
    @Override
    public void trackModification(String user) { auditSupport.trackModification(user); }
    @Override
    public AuditLog getAuditLog() { return auditSupport.getAuditLog(); }
    
    // Implement Serializable (User-specific serialization)
    @Override
    public byte[] serialize() {
        return (name + ":" + email).getBytes();
    }
    
    @Override
    public void deserialize(byte[] data) {
        String[] parts = new String(data).split(":");
        this.name = parts[0];
        this.email = parts[1];
    }
    
    // User methods can use all behaviors
    public void setName(String name, String modifiedBy) {
        this.name = name;
        trackModification(modifiedBy);
        notifyObservers();
    }
}
 
// User is now Observable, Serializable, AND Auditable!
// No inheritance limitation. Behaviors stack freely.

Composition Benefits for Multiple Behaviors

•Unlimited combinations — Include as many components as needed.
•Selective implementation — Choose exactly which behaviors to include.
•Independent evolution — Each component can be improved separately.
•Interface polymorphism — Implement multiple interfaces for type flexibility.
•Reusable components — The same component (ObserverSupport, AuditSupport) works in any class.

Traits and Mixins

Some languages (Scala traits, Rust traits, PHP traits, Python mixins) provide language-level support for composing behaviors. These are essentially composition mechanisms built into the language—further validating that composition is often what you need.

Advantage 5: Runtime Flexibility and Dynamic Behavior

Inheritance is static: the relationship between parent and child is fixed at compile time. You cannot change what class an object extends once it's instantiated.

Composition is dynamic: relationships between objects can be established, modified, or dissolved at runtime. This enables flexibility patterns that are impossible with inheritance alone.

Why Runtime Flexibility Matters

Real-world software often needs to:

Adapt behavior based on configuration loaded at startup
Change behavior in response to user preferences or A/B testing
Hot-swap implementations for feature flags
Gradually roll out new behaviors to subsets of users
Support plugins or extensions added after deployment

None of these are possible if behavior is determined by class hierarchy at compile time.

runtime-flexibility
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
// COMPOSITION: Runtime Behavior Switching
 
public interface PaymentProcessor {
    PaymentResult process(Payment payment);
}
 
public class StripeProcessor implements PaymentProcessor {
    @Override
    public PaymentResult process(Payment payment) {
        // Stripe API integration
    }
}
 
public class PayPalProcessor implements PaymentProcessor {
    @Override
    public PaymentResult process(Payment payment) {
        // PayPal API integration
    }
}
 
public class FailoverProcessor implements PaymentProcessor {
    private final PaymentProcessor primary;
    private final PaymentProcessor fallback;
    
    @Override
    public PaymentResult process(Payment payment) {
        try {
            return primary.process(payment);
        } catch (ProcessorUnavailableException e) {
            return fallback.process(payment);  // Automatic failover!
        }
    }
}
 
public class PaymentService {
    private PaymentProcessor processor;  // Can change at runtime!
    
    public PaymentService(PaymentProcessor processor) {
        this.processor = processor;
    }
    
    // Runtime reconfiguration
    public void setProcessor(PaymentProcessor newProcessor) {
        this.processor = newProcessor;
    }
    
    public PaymentResult processPayment(Payment payment) {
        return processor.process(payment);
    }
}
 
// RUNTIME FLEXIBILITY IN ACTION:
 
// Startup: Use configuration to choose processor
PaymentProcessor processor = config.useStripe() 
    ? new StripeProcessor() 
    : new PayPalProcessor();
    
PaymentService service = new PaymentService(processor);
 
// Runtime: Switch based on A/B test
if (abTestingService.isInVariant(user, "new-payment-flow")) {
    service.setProcessor(new NewFlowProcessor());
}
 
// Runtime: Add failover during high load
service.setProcessor(new FailoverProcessor(
    new StripeProcessor(),
    new PayPalProcessor()
));
 
// Runtime: Feature flag for beta features
if (featureFlags.isEnabled("crypto-payments")) {
    service.setProcessor(new CryptoProcessor());
}

The Decorator Pattern: Runtime Behavior Layering

The Decorator pattern is composition's answer to adding behavior dynamically. Instead of subclassing, you wrap objects with decorators that add functionality:

decorator-pattern
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
// Decorator Pattern: Dynamic Behavior Layering
 
public interface DataSource {
    void writeData(String data);
    String readData();
}
 
public class FileDataSource implements DataSource {
    private final String filename;
    
    @Override
    public void writeData(String data) {
        // Write to file
    }
    
    @Override
    public String readData() {
        // Read from file
    }
}
 
// Decorator base - also implements the interface
public abstract class DataSourceDecorator implements DataSource {
    protected final DataSource wrapped;
    
    public DataSourceDecorator(DataSource source) {
        this.wrapped = source;
    }
}
 
public class EncryptionDecorator extends DataSourceDecorator {
    @Override
    public void writeData(String data) {
        wrapped.writeData(encrypt(data));  // Add encryption
    }
    
    @Override
    public String readData() {
        return decrypt(wrapped.readData());  // Add decryption
    }
}
 
public class CompressionDecorator extends DataSourceDecorator {
    @Override
    public void writeData(String data) {
        wrapped.writeData(compress(data));  // Add compression
    }
    
    @Override
    public String readData() {
        return decompress(wrapped.readData());  // Add decompression
    }
}
 
// RUNTIME COMPOSITION: Stack any combination of behaviors!
 
// Plain file storage
DataSource source = new FileDataSource("data.txt");
 
// Add encryption at runtime
source = new EncryptionDecorator(source);
 
// Add compression on top (based on config)
if (config.compressionEnabled()) {
    source = new CompressionDecorator(source);
}
 
// Data flows: write → compress → encrypt → file
// Data flows: file → decrypt → decompress → read
 
// WITH INHERITANCE: You'd need these classes:
// - FileDataSource
// - EncryptedFileDataSource
// - CompressedFileDataSource
// - EncryptedCompressedFileDataSource
// - CompressedEncryptedFileDataSource (different order!)
// And you couldn't change at runtime!

Composition Enables Design Patterns

Many Gang of Four patterns (Strategy, Decorator, State, Composite, Proxy) are built on composition. These patterns exist precisely because inheritance alone cannot provide the required flexibility. Mastering composition unlocks the full power of these patterns.

Advantage 6: Superior Modularity and Reuse

Modularity is the degree to which a system's components can be separated and recombined. High modularity means components are self-contained and work in multiple contexts.

Inheritance Hinders Modularity

Inheritance ties code to specific hierarchies:

Hierarchical identity: A subclass is inseparably connected to its parent. You can't use the child without bringing along the entire ancestry.
Contextual constraints: Code written for one hierarchy can't easily be applied to another. Your EnhancedButton extends Button improvements only work for things that extend Button.
Extraction difficulty: Pulling code out of an inheritance hierarchy for reuse elsewhere requires refactoring the entire tree.

Composition Enables True Modularity

Composed components are context-independent. A well-designed component can be plugged into any system that needs its capabilities:

modularity-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
50
51
52
53
54
55
56
57
58
59
60
61
62
// COMPOSITION: Maximum Modularity
 
// A fully modular retry component
public class RetryExecutor {
    private final int maxRetries;
    private final Duration backoff;
    private final Predicate<Exception> retryCondition;
    
    public RetryExecutor(int maxRetries, Duration backoff, 
                         Predicate<Exception> retryCondition) {
        this.maxRetries = maxRetries;
        this.backoff = backoff;
        this.retryCondition = retryCondition;
    }
    
    public <T> T execute(Supplier<T> operation) throws Exception {
        int attempts = 0;
        while (true) {
            try {
                return operation.get();
            } catch (Exception e) {
                if (++attempts >= maxRetries || !retryCondition.test(e)) {
                    throw e;
                }
                Thread.sleep(backoff.toMillis() * attempts);
            }
        }
    }
}
 
// This component is COMPLETELY MODULAR:
// - No dependencies on specific hierarchies
// - Works with any operation that returns a value
// - Usable in ANY context
 
// Use in HTTP client:
RetryExecutor httpRetry = new RetryExecutor(3, Duration.ofSeconds(1),
    e -> e instanceof NetworkException);
String response = httpRetry.execute(() -> httpClient.get(url));
 
// Use in database access:
RetryExecutor dbRetry = new RetryExecutor(5, Duration.ofMillis(100),
    e -> e instanceof DeadlockException);
User user = dbRetry.execute(() -> userRepository.findById(id));
 
// Use in file operations:
RetryExecutor fileRetry = new RetryExecutor(2, Duration.ofSeconds(5),
    e -> e instanceof FileLockedException);
byte[] data = fileRetry.execute(() -> Files.readAllBytes(path));
 
// Use in message queue:
RetryExecutor mqRetry = new RetryExecutor(10, Duration.ofSeconds(30),
    e -> e instanceof BrokerUnavailableException);
mqRetry.execute(() -> { messageQueue.send(message); return null; });
 
// ONE component, reused across ENTIRE CODEBASE
// If we'd used inheritance, we'd need:
// - RetryableHttpClient extends HttpClient
// - RetryableUserRepository extends UserRepository  
// - RetryableFileReader extends FileReader
// - RetryableMessageQueue extends MessageQueue
// ...NO REUSE AT ALL

The Composability Principle

Small, focused components that do one thing well can be combined in myriad ways. This is the Unix philosophy applied to OOP:

Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features. Expect the output of every program to become the input to another.

Translated to composition:

Make each component do one thing well
To add capability, compose with other components rather than extending existing ones
Design components with composability in mind—accept and return interfaces

Signs of Good Modular Design

•Components are reused in multiple places — The same retry, caching, or logging component works everywhere.
•Adding features means adding components — Not modifying or extending existing classes.
•Components have narrow interfaces — Easy to understand, easy to compose.
•Testing is isolated — Each component has its own focused tests.
•Changes are localized — Modifying one component doesn't cascade to others.

Summary: Why Composition Wins

We've examined six fundamental advantages that make composition the preferred approach for most design decisions. Let's consolidate:

The Six Advantages of Composition
Advantage	Key Insight
Loose Coupling	Dependencies on interfaces, not implementations
Encapsulation Preservation	No exposure of internal details
Enhanced Testability	Components tested in isolation
No Single Inheritance Limit	Unlimited behavior combinations
Runtime Flexibility	Behavior changeable dynamically
Superior Modularity	Reusable across contexts

Key Takeaways

•Composition reduces coupling — Objects depend on interfaces, not implementation details, enabling independent evolution.
•Encapsulation stays intact — No protected member access or self-use pattern knowledge required.
•Testing becomes straightforward — Mock injected dependencies; test components in isolation.
•Multiple behaviors stack freely — Overcome single inheritance limits by composing interfaces.
•Runtime adaptation is possible — Swap components, add decorators, configure behavior dynamically.
•Modular components are reusable — The same component serves many contexts without modification.

What's Next:

Having established why composition is often preferred, the next page explores the flexibility benefits of composition in greater depth—examining how composition enables systems that gracefully adapt to change, support extension without modification, and maintain correctness as requirements evolve.

Page Complete

You now understand the six core advantages that make composition the winning choice for most design scenarios. These aren't theoretical benefits—they're practical advantages that affect daily development work: easier testing, safer changes, more reuse, and greater flexibility.