Refactoring to Composition - Learning Module

Loading content...

0/246

Step-by-step Refactoring Process

The Art of Surgical Refactoring

You've identified a candidate for refactoring—an inheritance hierarchy that's causing pain, slowing down development, and accumulating defects. Now comes the critical question: How do you actually perform the transformation without breaking the system?

Refactoring from inheritance to composition is not a single operation but a carefully choreographed sequence of small, verifiable steps. Each step maintains the system in a working state, allowing you to pause, verify correctness, and even roll back if necessary. This incremental approach transforms what could be a high-risk "big bang" rewrite into a controlled evolution.

What You Will Learn

By the end of this page, you will understand the systematic step-by-step process for refactoring inheritance to composition. You'll learn specific transformation techniques, when to apply each, and how to maintain system integrity throughout the process.

The Refactoring Philosophy

Before diving into specific techniques, we need to establish the philosophical foundation that guides safe refactoring. These principles apply beyond inheritance-to-composition transformations to all significant code restructuring.

1.1 The Mikado Method Principle

The Mikado Method, named after the game where you must remove sticks without disturbing others, teaches us that complex refactorings succeed through dependency-aware sequencing. The key insight: don't start by changing what seems most important. Instead, start by identifying all dependencies, then work backwards from the leaves of the dependency tree.

1.2 The Boy Scout Rule at Scale

"Leave the code better than you found it" scales to refactoring projects. Each step should:

Improve the code structure in a measurable way
Leave all tests passing
Be independently deployable
Not introduce new technical debt

Core Refactoring Principles

•Small steps — Each transformation should be small enough to fully understand and verify. If you can't explain exactly what changed, the step is too big.
•Continuous integration — Merge frequently. Long-lived refactoring branches become integration nightmares. Prefer trunk-based development with feature flags.
•Test before, test during, test after — Have passing tests before starting. Keep them passing throughout. Add new tests as structure emerges.
•Preserve behavior — Until the very end, the system's external behavior should not change. Refactoring changes structure, not semantics.
•Reversible progress — Each step should be revertible. If step 5 fails, you should be able to return to the state after step 4.

The Big Bang Antipattern

Resist the temptation to 'just rewrite it.' Big bang refactorings have a terrible track record. They take longer than estimated, introduce bugs, and often never complete. The system continues evolving while you rewrite, creating a moving target. Incremental refactoring works; rewrites rarely do.

The Transformation Roadmap

Refactoring from inheritance to composition follows a predictable pattern. While specific details vary by context, the overall structure remains consistent. Here is the roadmap:

Inheritance-to-Composition Refactoring Roadmap
Phase	Key Actions	Risk Level	Duration
Preparation	Ensure test coverage, document current behavior, identify dependencies	Low	1-2 days
Interface Extraction	Create interfaces representing the capabilities currently inherited	Low	1 day
Component Creation	Implement capability interfaces as standalone component classes	Medium	2-5 days
Delegation Introduction	Add composed objects to subclasses, delegate to them	Medium	2-3 days
Inheritance Elimination	Remove inheritance relationships, rely on composition	High	1-2 days
Cleanup	Remove dead code, consolidate interfaces, optimize	Low	1 day

Each phase has specific goals, techniques, and verification criteria. Let's explore each in detail.

Phase 1: Preparation

The preparation phase creates the safety net that makes confident refactoring possible. Skip this phase at your peril—most failed refactorings can trace their problems back to inadequate preparation.

3.1 Establish Test Coverage

Before modifying any code, ensure you have tests that capture the current behavior. These tests serve as your behavioral specification—if the tests pass after refactoring, you've preserved correctness.

Coverage targets:

Unit tests: All public methods of classes in the hierarchy should have tests
Integration tests: Key workflows involving the hierarchy should be covered
Edge cases: Error handling, boundary conditions, null inputs

If coverage is insufficient: Write characterization tests that capture current behavior, even if you're not sure that behavior is correct. The goal is documenting what IS, not what should be.

characterization_tests.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
// Characterization tests capture EXISTING behavior
// Even if the behavior seems wrong, document it
 
class NotificationBehaviorTests {
    
    @Test
    void emailNotification_withNullSubject_sendsWithEmptySubject() {
        // This might be a bug, but it's current behavior
        // Document it so refactoring doesn't accidentally "fix" it
        EmailNotification email = new EmailNotification(
            "user@example.com",
            null,  // null subject
            "Body text"
        );
        
        email.send();
        
        // Verify the null becomes empty string (current behavior)
        verify(smtpClient).send(argThat(msg -> 
            msg.getSubject().equals("")
        ));
    }
    
    @Test
    void smsNotification_oversizedContent_truncatesAt160Chars() {
        // Another behavior to preserve
        String longContent = "A".repeat(200);
        SmsNotification sms = new SmsNotification(
            "+1234567890",
            longContent
        );
        
        String formatted = sms.formatContent();
        
        assertEquals(160, formatted.length());
    }
}

3.2 Document the Current Structure

Create diagrams and documentation capturing:

The inheritance hierarchy (class diagrams)
Data flow between classes
External dependencies (APIs, databases, etc.)
Known quirks, workarounds, and tribal knowledge

This documentation helps you understand impact and serves as a reference while refactoring.

3.3 Identify All Dependencies

Map every place in the codebase that:

Instantiates classes in the hierarchy
Uses inheritance-specific features (e.g., instanceof checks)
Overrides methods from the hierarchy
Extends the hierarchy with new subclasses

This inventory guides the sequencing of changes. You must update dependents as you transform the hierarchy.

Automation Helps

Use IDE features like 'Find All References' and 'Find Usages' to automatically discover dependencies. Static analysis tools can generate dependency graphs. Invest in understanding your IDE's refactoring support before starting.

Phase 2: Interface Extraction

Interface extraction creates the abstractions that composition will use. This phase identifies the capabilities embedded in the inheritance hierarchy and expresses them as explicit interfaces.

4.1 Identify Capability Boundaries

Analyze your base class and its subclasses. Ask: What distinct behaviors or capabilities exist? Look for:

Groups of methods that work together
Methods that some subclasses override while others don't
Methods that relate to different concerns (formatting vs. sending vs. validating)

Each distinct capability becomes a candidate interface.

capability_identification.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
// BEFORE: Methods mixed in base class
 
abstract class Notification {
    protected String recipient;
    protected String content;
    
    // Capability 1: Content formatting
    public abstract String formatContent();   // ← Formatting concern
    
    // Capability 2: Validation
    public abstract boolean validate();       // ← Validation concern
    
    // Capability 3: Delivery
    public abstract void send();              // ← Delivery concern
    
    // Capability 4: Retry logic (some subclasses override, some don't)
    public void sendWithRetry(int maxAttempts) {
        for (int i = 0; i < maxAttempts; i++) {
            try {
                send();
                return;
            } catch (Exception e) {
                if (i == maxAttempts - 1) throw e;
                sleep(exponentialBackoff(i));
            }
        }
    }
}
 
// IDENTIFIED CAPABILITIES:
// 1. ContentFormatter - formatContent()
// 2. Validator - validate()  
// 3. DeliveryChannel - send()
// 4. RetryPolicy - sendWithRetry() logic

4.2 Extract Interfaces

For each identified capability, create an interface. Initially, these interfaces may look like they're extracting a single method—that's fine. The granularity can be refined later.

extracted_interfaces.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
// AFTER: Extracted capability interfaces
 
/**
 * Responsible for transforming content into format appropriate 
 * for the delivery channel.
 */
interface ContentFormatter {
    String format(String rawContent, FormattingContext context);
}
 
/**
 * Validates that a notification is well-formed and ready to send.
 */
interface NotificationValidator {
    ValidationResult validate(NotificationData data);
}
 
/**
 * Handles the actual delivery of a notification to a recipient.
 */
interface DeliveryChannel {
    DeliveryResult deliver(FormattedNotification notification);
    boolean supportsRecipient(String recipient);
}
 
/**
 * Defines how failed deliveries should be retried.
 */
interface RetryPolicy {
    boolean shouldRetry(int attemptNumber, Exception lastError);
    Duration getDelay(int attemptNumber);
}
 
// Supporting types for cleaner interfaces
record FormattingContext(String recipientType, Map<String, String> metadata) {}
record NotificationData(String recipient, String content, Map<String, Object> attributes) {}
record FormattedNotification(String content, Map<String, String> headers) {}
record ValidationResult(boolean valid, List<String> errors) {}
record DeliveryResult(boolean success, String messageId, String error) {}

Interface Segregation

Prefer multiple focused interfaces over one large interface. This follows the Interface Segregation Principle (ISP). It's easier to compose small interfaces than to implement large ones where you only need a subset of capabilities.

4.3 Verification Checkpoint

After extracting interfaces:

All tests still pass (no behavior changed yet)
Each interface represents a cohesive capability
Interface methods are general enough for multiple implementations
Interfaces don't reference inheritance-specific concepts

Phase 3: Component Creation

With interfaces defined, now implement them as standalone components. This is where the logic currently embedded in the inheritance hierarchy gets extracted into composable pieces.

5.1 Extract Implementation to Components

For each interface, create concrete implementations that encapsulate the previously inherited behavior. Each implementation should be:

Self-contained: All dependencies injected, no reliance on inheritance
Single-purpose: Does one thing well
Testable: Can be unit tested in isolation

component_implementations.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
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
// Extracted Component Implementations
 
// ContentFormatter implementations
class HtmlEmailFormatter implements ContentFormatter {
    private final TemplateEngine templateEngine;
    
    public HtmlEmailFormatter(TemplateEngine templateEngine) {
        this.templateEngine = templateEngine;
    }
    
    @Override
    public String format(String rawContent, FormattingContext context) {
        Map<String, Object> variables = Map.of(
            "content", rawContent,
            "recipientType", context.recipientType(),
            "metadata", context.metadata()
        );
        return templateEngine.render("email-template.html", variables);
    }
}
 
class PlainTextFormatter implements ContentFormatter {
    private final int maxLength;
    
    public PlainTextFormatter(int maxLength) {
        this.maxLength = maxLength;
    }
    
    @Override
    public String format(String rawContent, FormattingContext context) {
        if (rawContent.length() <= maxLength) {
            return rawContent;
        }
        return rawContent.substring(0, maxLength - 3) + "...";
    }
}
 
class SmsFormatter implements ContentFormatter {
    private static final int SMS_LIMIT = 160;
    private final String optOutSuffix;
    
    public SmsFormatter(String optOutSuffix) {
        this.optOutSuffix = optOutSuffix;
    }
    
    @Override
    public String format(String rawContent, FormattingContext context) {
        int availableLength = SMS_LIMIT - optOutSuffix.length();
        String truncated = rawContent.length() > availableLength 
            ? rawContent.substring(0, availableLength) 
            : rawContent;
        return truncated + optOutSuffix;
    }
}
 
// DeliveryChannel implementations
class SmtpDeliveryChannel implements DeliveryChannel {
    private final SmtpClient smtpClient;
    
    public SmtpDeliveryChannel(SmtpClient smtpClient) {
        this.smtpClient = smtpClient;
    }
    
    @Override
    public DeliveryResult deliver(FormattedNotification notification) {
        try {
            String messageId = smtpClient.send(
                notification.headers().get("to"),
                notification.headers().get("subject"),
                notification.content()
            );
            return new DeliveryResult(true, messageId, null);
        } catch (SmtpException e) {
            return new DeliveryResult(false, null, e.getMessage());
        }
    }
    
    @Override
    public boolean supportsRecipient(String recipient) {
        return recipient.contains("@");  // Simple email check
    }
}
 
class TwilioSmsChannel implements DeliveryChannel {
    private final TwilioClient twilioClient;
    
    public TwilioSmsChannel(TwilioClient twilioClient) {
        this.twilioClient = twilioClient;
    }
    
    @Override
    public DeliveryResult deliver(FormattedNotification notification) {
        try {
            String sid = twilioClient.sendSms(
                notification.headers().get("to"),
                notification.content()
            );
            return new DeliveryResult(true, sid, null);
        } catch (TwilioException e) {
            return new DeliveryResult(false, null, e.getMessage());
        }
    }
    
    @Override
    public boolean supportsRecipient(String recipient) {
        return recipient.startsWith("+");  // Phone number check
    }
}

5.2 Implement RetryPolicy Variants

Retry policies are excellent candidates for composition—they parameterize behavior that previously might have been scattered across subclasses or hardcoded.

retry_policy_implementations.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
// RetryPolicy implementations
 
class NoRetryPolicy implements RetryPolicy {
    @Override
    public boolean shouldRetry(int attemptNumber, Exception lastError) {
        return false;
    }
    
    @Override
    public Duration getDelay(int attemptNumber) {
        return Duration.ZERO;
    }
}
 
class ExponentialBackoffRetryPolicy implements RetryPolicy {
    private final int maxRetries;
    private final Duration baseDelay;
    private final Set<Class<? extends Exception>> retryableExceptions;
    
    public ExponentialBackoffRetryPolicy(
            int maxRetries, 
            Duration baseDelay,
            Set<Class<? extends Exception>> retryableExceptions) {
        this.maxRetries = maxRetries;
        this.baseDelay = baseDelay;
        this.retryableExceptions = retryableExceptions;
    }
    
    @Override
    public boolean shouldRetry(int attemptNumber, Exception lastError) {
        if (attemptNumber >= maxRetries) return false;
        return retryableExceptions.stream()
            .anyMatch(clazz -> clazz.isInstance(lastError));
    }
    
    @Override
    public Duration getDelay(int attemptNumber) {
        // Exponential: 1s, 2s, 4s, 8s...
        long multiplier = (long) Math.pow(2, attemptNumber);
        return baseDelay.multipliedBy(multiplier);
    }
}
 
class ConstantDelayRetryPolicy implements RetryPolicy {
    private final int maxRetries;
    private final Duration delay;
    
    public ConstantDelayRetryPolicy(int maxRetries, Duration delay) {
        this.maxRetries = maxRetries;
        this.delay = delay;
    }
    
    @Override
    public boolean shouldRetry(int attemptNumber, Exception lastError) {
        return attemptNumber < maxRetries;
    }
    
    @Override
    public Duration getDelay(int attemptNumber) {
        return delay;
    }
}

5.3 Test Components in Isolation

Before integrating components, test them independently. This catches bugs early and builds confidence in each building block.

component_unit_tests.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
// Unit tests for extracted components
 
class SmsFormatterTest {
    @Test
    void format_longContent_truncatesAndAddsOptOut() {
        SmsFormatter formatter = new SmsFormatter(" STOP to opt-out");
        String content = "A".repeat(160);  // Too long
        
        String result = formatter.format(content, new FormattingContext("", Map.of()));
        
        assertEquals(160, result.length());
        assertTrue(result.endsWith(" STOP to opt-out"));
    }
    
    @Test
    void format_shortContent_preservesContent() {
        SmsFormatter formatter = new SmsFormatter(" STOP");
        String content = "Hello World";
        
        String result = formatter.format(content, new FormattingContext("", Map.of()));
        
        assertEquals("Hello World STOP", result);
    }
}
 
class ExponentialBackoffRetryPolicyTest {
    @Test
    void shouldRetry_withinMaxRetries_returnsTrue() {
        RetryPolicy policy = new ExponentialBackoffRetryPolicy(
            3, 
            Duration.ofSeconds(1),
            Set.of(IOException.class)
        );
        
        assertTrue(policy.shouldRetry(0, new IOException()));
        assertTrue(policy.shouldRetry(1, new IOException()));
        assertTrue(policy.shouldRetry(2, new IOException()));
        assertFalse(policy.shouldRetry(3, new IOException()));
    }
    
    @Test
    void getDelay_calculatesExponentialBackoff() {
        RetryPolicy policy = new ExponentialBackoffRetryPolicy(
            5, 
            Duration.ofSeconds(1),
            Set.of(Exception.class)
        );
        
        assertEquals(Duration.ofSeconds(1), policy.getDelay(0));
        assertEquals(Duration.ofSeconds(2), policy.getDelay(1));
        assertEquals(Duration.ofSeconds(4), policy.getDelay(2));
        assertEquals(Duration.ofSeconds(8), policy.getDelay(3));
    }
}

Phase 4: Delegation Introduction

This is the pivotal phase where inheritance begins transitioning to composition. The technique is introduce delegation—classes start holding references to components and forwarding calls to them, rather than inheriting behavior.

6.1 The Parallel Run Strategy

For safety, introduce delegation alongside existing inheritance rather than replacing it immediately:

Add component fields to existing classes
Delegate to components but keep inherited implementation as fallback
Verify components produce identical results
Remove inheritance once delegation is proven

delegation_introduction.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
// Step 1: Add component fields alongside existing structure
 
class EmailNotification extends Notification {
    // Existing fields
    private String subject;
    private List<Attachment> attachments;
    
    // NEW: Injected components
    private final ContentFormatter formatter;
    private final DeliveryChannel channel;
    private final NotificationValidator validator;
    
    // Transition constructor - accepts both old and new dependencies
    public EmailNotification(
            String recipient, String content, String subject,
            // New component dependencies
            ContentFormatter formatter,
            DeliveryChannel channel,
            NotificationValidator validator) {
        super(recipient, content);
        this.subject = subject;
        this.formatter = formatter;
        this.channel = channel;
        this.validator = validator;
    }
    
    // Step 2: Migrate methods to use delegation
    @Override
    public String formatContent() {
        // During transition, use feature flag to control behavior
        if (FeatureFlags.USE_NEW_FORMATTER) {
            return formatter.format(content, createContext());
        }
        // Fall back to original implementation
        return originalFormatContent();
    }
    
    @Override
    public void send() {
        if (FeatureFlags.USE_NEW_DELIVERY) {
            FormattedNotification notification = new FormattedNotification(
                formatContent(),
                Map.of("to", recipient, "subject", subject)
            );
            DeliveryResult result = channel.deliver(notification);
            if (!result.success()) {
                throw new DeliveryException(result.error());
            }
        } else {
            originalSend();
        }
    }
    
    // Keep original implementations during transition
    private String originalFormatContent() {
        // Original HTML formatting logic
        return "<html><body>" + content + "</body></html>";
    }
    
    private void originalSend() {
        // Original SMTP logic
        SmtpClient.getInstance().send(recipient, subject, formatContent());
    }
    
    private FormattingContext createContext() {
        return new FormattingContext("email", Map.of("subject", subject));
    }
}

6.2 Verification During Delegation

To ensure delegation preserves behavior, implement parallel execution with comparison:

parallel_verification.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
// Parallel execution to verify behavioral equivalence
 
@Override
public String formatContent() {
    String oldResult = originalFormatContent();
    String newResult = formatter.format(content, createContext());
    
    if (FeatureFlags.PARALLEL_VERIFICATION) {
        if (!oldResult.equals(newResult)) {
            // Log discrepancy for investigation
            Logger.warn("Formatter mismatch: old='{}' new='{}'", 
                oldResult, newResult);
            metrics.increment("formatter.mismatch");
            
            // During verification phase, return old result
            return oldResult;
        } else {
            metrics.increment("formatter.match");
        }
    }
    
    // Once verified, return new result
    return FeatureFlags.USE_NEW_FORMATTER ? newResult : oldResult;
}

Shadow Mode Testing

Run the new delegation path in 'shadow mode' in production—execute both paths, compare results, but only use the old path's result. This catches discrepancies on real production data without impacting users.

6.3 Migrate Subclasses Incrementally

Don't migrate all subclasses simultaneously. Instead:

Start with the simplest subclass (fewest overrides)
Complete the delegation migration for that subclass
Verify in production
Move to the next subclass
Repeat until all subclasses use delegation

This approach limits the blast radius if something goes wrong.

Phase 5: Inheritance Elimination

Once delegation is fully verified, you can remove the inheritance relationships. This is the highest-risk phase but should be straightforward if previous phases were done correctly.

7.1 Remove Base Class Dependencies

For each subclass:

Remove the extends clause
Move any needed state from the base class to the class itself
Ensure all behavior comes from composed components
Remove override annotations
Update tests

inheritance_elimination.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
94
// BEFORE: Inheritance-based
 
class EmailNotification extends Notification {
    private String subject;
    private final ContentFormatter formatter;
    private final DeliveryChannel channel;
    
    @Override
    public String formatContent() {
        return formatter.format(content, createContext());
    }
    
    @Override
    public void send() {
        // delegation logic
    }
}
 
// AFTER: Composition-based (no inheritance)
 
class EmailNotification implements Sendable {
    // State previously inherited now owned
    private final String recipient;
    private final String content;
    private final String subject;
    
    // Composed components
    private final ContentFormatter formatter;
    private final DeliveryChannel channel;
    private final NotificationValidator validator;
    private final RetryPolicy retryPolicy;
    
    public EmailNotification(
            String recipient,
            String content,
            String subject,
            ContentFormatter formatter,
            DeliveryChannel channel,
            NotificationValidator validator,
            RetryPolicy retryPolicy) {
        this.recipient = recipient;
        this.content = content;
        this.subject = subject;
        this.formatter = formatter;
        this.channel = channel;
        this.validator = validator;
        this.retryPolicy = retryPolicy;
    }
    
    @Override
    public void send() {
        // Validate
        ValidationResult validation = validator.validate(
            new NotificationData(recipient, content, Map.of("subject", subject))
        );
        if (!validation.valid()) {
            throw new InvalidNotificationException(validation.errors());
        }
        
        // Format
        String formatted = formatter.format(content, createContext());
        
        // Deliver with retry
        deliverWithRetry(new FormattedNotification(
            formatted,
            Map.of("to", recipient, "subject", subject)
        ));
    }
    
    private void deliverWithRetry(FormattedNotification notification) {
        int attempt = 0;
        Exception lastError = null;
        
        while (true) {
            try {
                DeliveryResult result = channel.deliver(notification);
                if (result.success()) return;
                throw new DeliveryException(result.error());
            } catch (Exception e) {
                lastError = e;
                if (!retryPolicy.shouldRetry(attempt, e)) {
                    throw new DeliveryException("Delivery failed after retries", e);
                }
                sleep(retryPolicy.getDelay(attempt));
                attempt++;
            }
        }
    }
}
 
// The Sendable interface replaces the abstract Notification class
interface Sendable {
    void send();
}

7.2 Introduce Factory for Object Creation

With inheritance gone, object creation becomes more complex (more dependencies to inject). Introduce factories to encapsulate this complexity:

notification_factory.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
// Factory encapsulates composition complexity
 
class NotificationFactory {
    private final ContentFormatter emailFormatter;
    private final ContentFormatter smsFormatter;
    private final DeliveryChannel smtpChannel;
    private final DeliveryChannel twilioChannel;
    private final NotificationValidator validator;
    
    public NotificationFactory(
            TemplateEngine templateEngine,
            SmtpClient smtpClient,
            TwilioClient twilioClient) {
        this.emailFormatter = new HtmlEmailFormatter(templateEngine);
        this.smsFormatter = new SmsFormatter(" Reply STOP to unsubscribe");
        this.smtpChannel = new SmtpDeliveryChannel(smtpClient);
        this.twilioChannel = new TwilioSmsChannel(twilioClient);
        this.validator = new CompositeValidator(
            new RecipientValidator(),
            new ContentLengthValidator()
        );
    }
    
    public Sendable createEmailNotification(
            String recipient, 
            String content, 
            String subject) {
        return new EmailNotification(
            recipient,
            content,
            subject,
            emailFormatter,
            smtpChannel,
            validator,
            new ExponentialBackoffRetryPolicy(3, Duration.ofSeconds(1), 
                Set.of(IOException.class))
        );
    }
    
    public Sendable createSmsNotification(String phoneNumber, String content) {
        return new SmsNotification(
            phoneNumber,
            content,
            smsFormatter,
            twilioChannel,
            validator,
            new ConstantDelayRetryPolicy(2, Duration.ofSeconds(5))
        );
    }
    
    public Sendable createTransactionalEmail(
            String recipient, 
            String orderId, 
            String content) {
        // Compose with specific components for transactional emails
        return new EmailNotification(
            recipient,
            content,
            "Order Confirmation: " + orderId,
            new TransactionalEmailFormatter(orderId),  // Different formatter
            smtpChannel,
            validator,
            new NoRetryPolicy()  // Transactional = no retry (idempotency concern)
        );
    }
}

Phase 6: Cleanup

With inheritance eliminated, cleanup ensures the codebase is in its cleanest possible state.

8.1 Remove Dead Code

Delete the old base class (if no longer needed)
Remove any transition code (feature flags, parallel execution)
Delete characterization tests that are now redundant
Remove unused intermediate abstract classes

8.2 Consolidate Interfaces

Review the interfaces created during extraction. You may find:

Interfaces that are too fine-grained and should be combined
Interfaces that are unused and should be deleted
Opportunities to simplify interface hierarchies

8.3 Update Documentation

Update architecture diagrams to reflect new structure
Document the composition patterns used
Update onboarding materials for new team members
Archive (don't delete) the original design documentation for historical context

Celebrate the Win

Successful refactoring from inheritance to composition is a significant achievement. Document the improvement metrics: reduced bug rates, faster feature development, simpler code. Share the success with stakeholders to build support for future refactoring investments.

Summary: The Refactoring Process

Key Takeaways

•Preparation is non-negotiable — Test coverage and dependency mapping prevent disasters during refactoring
•Extract interfaces to express capabilities — Think in terms of 'what this can do' not 'what this is'
•Create standalone components — Each component should be testable and usable independently
•Introduce delegation incrementally — Run old and new paths in parallel before switching
•Eliminate inheritance only when proven — Remove extends clauses after delegation is verified
•Factories hide complexity — Use factories to manage the increased construction complexity of composed objects

What's Next

The next page covers maintaining behavioral correctness during refactoring—how to ensure the system behaves identically after transformation, techniques for regression prevention, and strategies for handling edge cases discovered during the process.