Identifying Refactoring Candidates - Refactoring from Inheritance to Composition | OneNoughtOne

0/290

System Design (LLD)Refactoring from Inheritance to Composition

Refactoring from Inheritance to Composition

LevelAdvanced

Duration60 mins

TopicRefactoring from Inheritance to Composition

1 / 4

Identifying Refactoring Candidates

The Hidden Cost of Inherited Debt

Every seasoned engineer has encountered it: a codebase where adding a simple feature requires modifying a dozen files, where a single change in a base class ripples unpredictably through the entire system, where the class hierarchy has grown into an impenetrable labyrinth. These are the symptoms of inheritance debt—the accumulated cost of inheritance-based designs that have outlived their usefulness.

The challenge isn't recognizing that something is wrong—that's usually painfully obvious. The challenge is knowing when to act and what to look for. Not every inheritance hierarchy needs refactoring, and premature optimization can waste valuable engineering time. But waiting too long transforms a manageable refactoring into a multi-quarter project that no one wants to own.

What You Will Learn

By the end of this page, you will be able to systematically identify inheritance-based designs that are candidates for refactoring to composition. You'll understand the specific code smells, structural patterns, and business signals that indicate when inheritance has become a liability rather than an asset.

Why Identification Matters

Refactoring from inheritance to composition is a significant undertaking. It requires careful planning, comprehensive testing, and often coordinated changes across multiple teams. Making the decision to refactor—or not to refactor—is itself a critical skill that separates experienced architects from those who are still developing their judgment.

The cost of premature refactoring:

Refactoring when it's not needed wastes engineering resources that could deliver business value. It introduces risk into stable systems. It can demoralize teams who feel their original work is being dismissed rather than evolved.

The cost of delayed refactoring:

Waiting too long allows inheritance debt to compound. What could have been a two-week refactor becomes a three-month project. New features continue to lock in problematic patterns. Team members who understand the original design leave, taking institutional knowledge with them.

The identification skill:

The ability to accurately identify refactoring candidates—neither too early nor too late—is what distinguishes engineers who can sustainably evolve systems from those who either over-engineer or accumulate crushing technical debt.

Goals of Accurate Identification

•Maximize ROI — Focus refactoring effort on hierarchies causing the most pain, not those that merely violate theoretical principles
•Minimize Risk — Identify candidates where refactoring can be done incrementally, reducing the blast radius of changes
•Build Consensus — Provide concrete evidence that justifies the investment, making it easier to align stakeholders
•Scope Appropriately — Understand the full extent of changes required before committing to a refactoring project

Code Smells Indicating Inheritance Problems

Code smells are surface-level indicators that something deeper may be wrong. When it comes to inheritance problems, certain smells appear with remarkable consistency. Learning to recognize these patterns is the first step in identifying refactoring candidates.

Smells vs. Symptoms

A code smell doesn't necessarily indicate a problem—it indicates the possibility of a problem. Multiple smells appearing together, or a single smell that's particularly severe, increases the likelihood that refactoring is warranted. Use smells as triggers for deeper investigation, not automatic refactoring decisions.

2.1 The Refused Bequest Smell

What it looks like: A subclass inherits methods or properties that it doesn't use, or worse, that it must actively disable or override with empty implementations.

Why it indicates a problem: The Liskov Substitution Principle states that subclasses should be substitutable for their parent classes. When a subclass refuses parts of its inheritance, it's signaling that the hierarchy doesn't accurately model the domain.

Example scenario: Consider a Bird class with a fly() method. When you add Penguin as a subclass, you must override fly() to throw an exception or do nothing. The penguin "refuses" the flying capability—a clear sign that the Bird hierarchy models the wrong abstraction.

refused_bequest_smell.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
// The Base Class - seems reasonable at first
abstract class Bird {
    protected String name;
    
    public Bird(String name) {
        this.name = name;
    }
    
    // All birds fly... right?
    public abstract void fly();
    
    public abstract void makeSound();
}
 
// Works perfectly for flying birds
class Eagle extends Bird {
    public Eagle() {
        super("Eagle");
    }
    
    @Override
    public void fly() {
        System.out.println("Eagle soars majestically through the sky");
    }
    
    @Override
    public void makeSound() {
        System.out.println("Screech!");
    }
}
 
// 🚨 REFUSED BEQUEST: Penguin must "refuse" the fly() inheritance
class Penguin extends Bird {
    public Penguin() {
        super("Penguin");
    }
    
    @Override
    public void fly() {
        // What do we do here?
        // Option 1: Throw an exception (breaks Liskov)
        throw new UnsupportedOperationException("Penguins cannot fly");
        
        // Option 2: Do nothing (misleading, violates interface contract)
        // return;
        
        // Option 3: Print a message (band-aid solution)
        // System.out.println("*waddles instead*");
    }
    
    @Override
    public void makeSound() {
        System.out.println("*penguin sounds*");
    }
    
    // Penguins have a capability that other birds don't
    public void swim() {
        System.out.println("Penguin swims gracefully");
    }
}
 
// Client code that now has landmines
class BirdSanctuary {
    public void releaseBird(Bird bird) {
        bird.fly();  // 💥 Explodes if bird is a Penguin
    }
}

2.2 The Parallel Inheritance Hierarchies Smell

What it looks like: Every time you create a new subclass in one hierarchy, you find yourself creating a corresponding subclass in another hierarchy.

Why it indicates a problem: This tight coupling between hierarchies means changes must be synchronized, multiplying maintenance effort. It often indicates that inheritance is being used to manage what should be independent dimensions of variation.

Example scenario: You have Report and ReportGenerator hierarchies. When you add MonthlyReport, you must also add MonthlyReportGenerator. When you add QuarterlyReport, you need QuarterlyReportGenerator. The hierarchies grow in lockstep—a red flag.

parallel_hierarchies_smell.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
// 🚨 PARALLEL INHERITANCE HIERARCHIES
// Note how every Report subclass requires a matching Generator subclass
 
// Hierarchy 1: Reports
abstract class Report {
    abstract String getTitle();
    abstract Map<String, Object> getData();
}
 
class MonthlyReport extends Report {
    @Override String getTitle() { return "Monthly Report"; }
    @Override Map<String, Object> getData() { /* ... */ }
}
 
class QuarterlyReport extends Report {
    @Override String getTitle() { return "Quarterly Report"; }
    @Override Map<String, Object> getData() { /* ... */ }
}
 
class AnnualReport extends Report {
    @Override String getTitle() { return "Annual Report"; }
    @Override Map<String, Object> getData() { /* ... */ }
}
 
// Hierarchy 2: Generators (PARALLEL to Reports!)
abstract class ReportGenerator {
    abstract void generate(Report report);
}
 
class MonthlyReportGenerator extends ReportGenerator {
    @Override void generate(Report report) {
        // Can only work with MonthlyReport
        MonthlyReport mr = (MonthlyReport) report;  // 🚨 Cast required!
        // ... monthly-specific generation logic
    }
}
 
class QuarterlyReportGenerator extends ReportGenerator {
    @Override void generate(Report report) {
        QuarterlyReport qr = (QuarterlyReport) report;  // 🚨 Another cast!
        // ... quarterly-specific generation logic
    }
}
 
class AnnualReportGenerator extends ReportGenerator {
    @Override void generate(Report report) {
        AnnualReport ar = (AnnualReport) report;  // 🚨 Yet another cast!
        // ... annual-specific generation logic
    }
}
 
// Every new report type = TWO new classes
// New report type: ComplianceReport requires ComplianceReportGenerator
// The hierarchies MUST grow in parallel

2.3 The Speculative Generality Smell

What it looks like: Abstract classes or elaborate hierarchies exist "just in case" they're needed someday, but currently have only one concrete implementation.

Why it indicates a problem: Unused abstraction layers add complexity without providing value. They make the code harder to understand and maintain, and the guessed-at extension points often don't match actual future requirements.

Example scenario: A DataStore abstract class with PostgresDataStore as the only implementation, created because "we might support MySQL someday." Two years later, no other databases have been added, but every data access goes through unnecessary abstraction layers.

2.4 The Shotgun Surgery Smell

What it looks like: Making a single conceptual change requires modifying many classes across the inheritance hierarchy.

Why it indicates a problem: This usually indicates that responsibilities are scattered incorrectly across the hierarchy. Changes that should be localized instead propagate through multiple levels, increasing the risk of missed modifications and bugs.

Example scenario: Adding a new audit field requires modifying the base Entity class, all intermediate abstract classes, and every concrete subclass—a change in one place fans out to dozens of files.

Summary: Code Smells Indicating Inheritance Problems
Smell	Key Indicator	Severity	Refactoring Urgency
Refused Bequest	Subclasses override to disable functionality	High	Immediate—violates Liskov
Parallel Hierarchies	Adding one subclass requires adding another	High	High—coupling compounds
Speculative Generality	Abstract classes with single implementation	Medium	Low—simplify when touched
Shotgun Surgery	Small changes touch many hierarchy classes	High	High—indicates scattered responsibility

Structural Indicators

Beyond individual code smells, certain structural patterns in the overall design indicate inheritance hierarchies that are likely candidates for refactoring. These are often visible at the architecture level rather than in individual classes.

3.1 Deep Inheritance Hierarchies

The pattern: Class hierarchies that extend beyond 2-3 levels of depth.

Why it's problematic:

Cognitive load: Understanding a class requires understanding all ancestor classes
Fragile base class: Changes at any level can break descendants in unexpected ways
Rigidity: Deep hierarchies resist change because modifications cascade

Quantitative guideline: Hierarchies deeper than 3 levels should be scrutinized. Beyond 4 levels, refactoring should be actively considered. Beyond 5 levels, immediate refactoring is usually justified.

Exception: Framework classes (like UI widget hierarchies) may legitimately be deeper, but business domain classes rarely need such depth.

deep_hierarchy_example.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// 🚨 DEEP HIERARCHY: 5 levels deep
// Understanding SpecialDiscountPremiumVIPCustomer requires
// understanding 4 ancestor classes
 
class Entity { }                                    // Level 1
    class User extends Entity { }                   // Level 2
        class Customer extends User { }             // Level 3
            class PremiumCustomer extends Customer { }        // Level 4
                class VIPCustomer extends PremiumCustomer { } // Level 5
                    // What if we need VIPWithSpecialDiscount?
                    class SpecialDiscountVIPCustomer extends VIPCustomer { } // Level 6!
 
// Problems:
// 1. Where does "apply discount logic" live?
// 2. How do you create a "Premium but not VIP" with special discounts?
// 3. What if VIP rules change? Do SpecialDiscountVIP customers inherit the change?
 
// The hierarchy encodes business rules in structure
// But business rules change, and structure is expensive to change

3.2 Wide Inheritance Hierarchies

The pattern: A single base class with many (10+) direct subclasses.

Why it's problematic:

Switch/case proliferation: Client code often ends up with giant switch statements based on type
Modification amplification: Changes to the base class interface affect all subclasses
Unclear abstraction: The base class often becomes a grab-bag of methods, some relevant to some subclasses but not others

What it suggests: The subclasses likely represent variations that should be modeled as composed behaviors rather than inherited types.

3.3 Diamond-Like Patterns (Without Multiple Inheritance)

The pattern: Even in single-inheritance languages, you see workarounds that effectively create diamond patterns—where a logical subclass would need to inherit from two incompatible parents.

How it manifests:

Utility classes or mixins that duplicate functionality across branches
Interfaces used to "simulate" the missing parent
Delegation that partially reimplements inherited behavior

Why it indicates composition need: If you're fighting to achieve multiple inheritance effects, composition would give you those effects naturally without the architectural contortions.

The Inheritance–Composition Boundary

When you find yourself wishing for multiple inheritance, that's almost always a signal that composition is the right model. Composition allows objects to have multiple capabilities without the semantic baggage of inheritance.

3.4 Violation of the Liskov Substitution Principle (LSP)

The pattern: Client code that checks the specific type of objects before operating on them, or catches exceptions that indicate an object doesn't support an inherited method.

Detection techniques:

Search for instanceof checks in client code
Look for catch blocks that handle UnsupportedOperationException or similar
Find comments like "// This shouldn't happen for XYZ type"

Why it's serious: LSP violations indicate that the inheritance hierarchy is lying about substitutability. The type system promises something that runtime behavior doesn't deliver.

lsp_violation_detection.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
// 🚨 LSP VIOLATION INDICATORS IN CLIENT CODE
 
class PaymentProcessor {
    public void processPayment(Payment payment) {
        // Type checking is a red flag
        if (payment instanceof CashPayment) {
            // Cash doesn't need authorization
            processCashPayment((CashPayment) payment);
        } else if (payment instanceof CreditCardPayment) {
            // Credit cards need authorization
            authorizeThenProcess((CreditCardPayment) payment);
        } else if (payment instanceof CryptoPayment) {
            // Crypto has completely different flow
            processCryptoPayment((CryptoPayment) payment);
        }
        // 🚨 Every new payment type requires modifying this method
    }
}
 
// Also suspicious: exception handling that checks types
class OrderService {
    public void submitOrder(Order order) {
        try {
            order.validate();
        } catch (UnsupportedOperationException e) {
            // Some order types don't support validation?
            // This means Order.validate() is a broken contract
            if (order instanceof LegacyOrder) {
                // Just skip validation for legacy orders
                // 🚨 LSP violation: LegacyOrder isn't truly an Order
            }
        }
    }
}

Business and Operational Signals

Technical smells and structural patterns are only part of the picture. Business and operational signals often provide the strongest justification for refactoring—and the most compelling arguments for stakeholders who need to approve the investment.

Business Signals That Indicate Refactoring Need

•Feature Velocity Decline — New features in the affected area take 2-3x longer than similar features elsewhere. Sprint velocity has noticeably dropped.
•Escalating Bug Counts — Fix rates in the inheritance hierarchy lag behind the rest of the codebase. Fixes frequently introduce new bugs (regression rate).
•Onboarding Friction — New team members take significantly longer to become productive in code touching the hierarchy. The learning curve is disproportionately steep.
•Cross-Cutting Feature Requests — Business requests features that cut across the hierarchy ("all customer types need X") which require modifying every subclass.
•Reluctance to Touch the Code — Engineers actively avoid tasks involving the hierarchy. There's informal agreement that certain areas are "dangerous" to modify.

4.1 Measuring Feature Velocity Impact

To build a compelling case for refactoring, quantify the impact on delivery speed:

Method 1: Comparative Story Point Analysis

Compare estimated vs. actual story points for features in the affected area versus the overall codebase. A consistent 50%+ overrun in the affected area suggests structural problems.

Method 2: Lead Time Tracking

Measure how long features take from specification to production. If features touching the inheritance hierarchy consistently take 2-3x longer, that's concrete evidence.

Method 3: Change Failure Rate

Track how often changes to the hierarchy require hotfixes or rollbacks compared to changes elsewhere. A higher change failure rate indicates fragility.

Speaking the Language of Stakeholders

Technical debt arguments often fail to convince non-technical stakeholders. Instead, frame the problem in terms they understand: 'New features in this area cost 2x our baseline. A 3-week investment now would reduce that to 1.2x, paying back within 6 months.' Numbers and ROI projections are more persuasive than code smells.

4.2 Operational Red Flags

Sometimes inheritance problems manifest in runtime behavior rather than development friction:

Memory overhead: Deep inheritance hierarchies can cause object bloat as each level adds fields. Monitor memory usage for objects in the hierarchy.

Performance cliffs: Polymorphic dispatch through deep hierarchies can cause cache misses. Profile before assuming this is an issue, but be aware of the possibility.

Configuration explosion: If you find yourself needing to configure behavior at multiple hierarchy levels with complex override rules, the hierarchy is fighting against the flexibility you need.

The Identification Framework

Given all these signals—code smells, structural patterns, and business indicators—how do you systematically evaluate whether a particular inheritance hierarchy should be refactored? Use this structured framework to analyze candidates:

Refactoring Candidate Evaluation Framework
Dimension	Questions to Ask	Weight
Pain Level	How much active suffering is this causing? (blocked features, frequent bugs, team complaints)	High
Frequency of Change	How often does this hierarchy need modification? (Weekly = high priority)	High
Blast Radius	How much of the codebase depends on this hierarchy?	Medium
Refactoring Complexity	How difficult will the refactoring be? (scope, test coverage, team skill)	Medium
Strategic Importance	Does this affect systems that are critical to business priorities?	High
Alternatives	Are there workarounds that can defer the refactoring? At what cost?	Low

5.1 Applying the Framework: A Scoring Approach

For each candidate hierarchy, score these dimensions on a 1-5 scale:

Pain Level (1-5): 1 = minor annoyance, 5 = actively blocking work
Change Frequency (1-5): 1 = rarely touched, 5 = modified weekly
Blast Radius (1-5): 1 = isolated subsystem, 5 = touches everything
Complexity (1-5): 1 = straightforward, 5 = extremely complex (INVERT this score when prioritizing)
Strategic Importance (1-5): 1 = peripheral, 5 = core business function

Priority Score = (Pain × 2) + (Frequency × 2) + (Strategic × 1.5) + (Blast × 0.5) - Complexity

Higher scores indicate higher priority for refactoring. The complexity subtraction ensures you factor in the cost of the work, not just the benefit.

refactoring_priority_analysis.ts
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
// Practical Priority Analysis Template
 
interface RefactoringCandidate {
  name: string;
  painLevel: number;      // 1-5
  changeFrequency: number; // 1-5
  blastRadius: number;    // 1-5
  complexity: number;     // 1-5
  strategicImportance: number; // 1-5
}
 
function calculatePriority(candidate: RefactoringCandidate): number {
  return (
    (candidate.painLevel * 2) +
    (candidate.changeFrequency * 2) +
    (candidate.strategicImportance * 1.5) +
    (candidate.blastRadius * 0.5) -
    candidate.complexity
  );
}
 
// Example: Evaluate three candidate hierarchies
const candidates: RefactoringCandidate[] = [
  {
    name: "CustomerHierarchy (Entity → User → Customer → Premium → VIP)",
    painLevel: 4,           // Frequently causes bugs
    changeFrequency: 5,     // Modified almost weekly
    blastRadius: 4,         // Used throughout the system
    complexity: 4,          // Will require significant effort
    strategicImportance: 5, // Customer management is core business
  },
  {
    name: "ReportHierarchy (Report → Daily/Weekly/Monthly)",
    painLevel: 3,           // Annoying but manageable
    changeFrequency: 2,     // Rarely changed
    blastRadius: 2,         // Isolated to reporting module
    complexity: 2,          // Relatively simple refactor
    strategicImportance: 2, // Reporting is secondary function
  },
  {
    name: "PaymentHierarchy (Payment → Cash/Card/Crypto)",
    painLevel: 5,           // Blocking new payment integrations
    changeFrequency: 4,     // New payment types quarterly
    blastRadius: 3,         // Checkout flow only
    complexity: 3,          // Medium complexity
    strategicImportance: 5, // Revenue-critical
  },
];
 
// Calculate and sort by priority
const prioritized = candidates
  .map(c => ({ ...c, priority: calculatePriority(c) }))
  .sort((a, b) => b.priority - a.priority);
 
console.log("Refactoring Priorities:");
prioritized.forEach((c, i) => {
  console.log(`${i + 1}. ${c.name}: Priority Score = ${c.priority.toFixed(1)}`);
});
 
// Output:
// 1. PaymentHierarchy: Priority Score = 21.5
// 2. CustomerHierarchy: Priority Score = 20.5
// 3. ReportHierarchy: Priority Score = 9.0

Case Study: Identifying a Real Candidate

Let's walk through a realistic scenario of identifying a refactoring candidate in a production system.

Scenario: E-Commerce Notification System

A mid-sized e-commerce platform has a notification system built on an inheritance hierarchy. The system has been in production for 3 years and handles email, SMS, and push notifications. The team is struggling to add new notification types and integrate new delivery providers.

6.1 Current State Analysis

The existing hierarchy looks like this:

notification_hierarchy.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
// Current Inheritance Hierarchy
 
abstract class Notification {
    protected String recipient;
    protected String content;
    protected Priority priority;
    
    public abstract void send();
    public abstract void validate();
    public abstract String formatContent();
}
 
// Email branch
class EmailNotification extends Notification {
    private String subject;
    private List<Attachment> attachments;
    
    @Override public void send() { /* SMTP logic */ }
    @Override public void validate() { /* email validation */ }
    @Override public String formatContent() { /* HTML formatting */ }
}
 
class MarketingEmailNotification extends EmailNotification {
    private String campaignId;
    private boolean trackOpens;
    // Adds marketing-specific tracking
}
 
class TransactionalEmailNotification extends EmailNotification {
    private String orderId;
    // Adds order-related context
}
 
// SMS branch
class SmsNotification extends Notification {
    private String phoneNumber;
    
    @Override public void send() { /* Twilio API */ }
    @Override public void validate() { /* phone validation */ }
    @Override public String formatContent() { /* 160 char limit */ }
}
 
class PromotionalSmsNotification extends SmsNotification {
    private String promoCode;
    // Must include opt-out language
}
 
// Push branch
class PushNotification extends Notification {
    private String deviceToken;
    private String deepLink;
    
    @Override public void send() { /* Firebase/APNs */ }
    @Override public void validate() { /* token validation */ }
    @Override public String formatContent() { /* structured payload */ }
}
 
// ... hierarchy continues for each notification type and channel

6.2 Observed Problems

Code Smell Evidence:

Parallel Hierarchy: Adding "transactional" notifications required TransactionalEmailNotification, TransactionalSmsNotification, and TransactionalPushNotification—three classes for one concept.
Refused Bequest: SmsNotification can't use the attachments capability that makes sense for email. Rich content formatting in the base class is ignored by SMS.
Shotgun Surgery: Adding GDPR compliance fields required modifying 12 notification classes instead of one place.

Structural Evidence:

Hierarchy is 3 levels deep and growing
15+ concrete notification classes
Base class has methods that some subclasses don't use

Business Evidence:

Adding a new notification channel (Slack) estimated at 4 weeks due to class explosion
New provider integrations (switching from Twilio to alternate SMS provider) blocked by tight coupling
Team avoids notification-related features in sprint planning

6.3 Identification Decision

Applying the scoring framework:

Dimension	Score	Rationale
Pain Level	4	Teams actively avoiding the code
Change Frequency	4	Multiple changes per month
Blast Radius	3	Core communication system
Complexity	4	Deep hierarchy, many integrations
Strategic Importance	4	Customer communication is vital

Priority Score = (4×2) + (4×2) + (4×1.5) + (3×0.5) - 4 = 8 + 8 + 6 + 1.5 - 4 = 19.5

Verdict: Strong candidate for refactoring. The high scores across pain, frequency, and strategic importance outweigh the complexity cost. The business case (4 weeks to add Slack vs. estimated 3 days post-refactor) provides clear ROI.

Summary: Identifying Refactoring Candidates

We've established a comprehensive framework for identifying when inheritance-based designs should be refactored to composition. Let's consolidate the key takeaways:

Key Takeaways

•Code smells are signals, not mandates — Use them to trigger investigation, not automatic refactoring decisions
•Structural patterns reveal systemic issues — Deep hierarchies, wide hierarchies, and LSP violations indicate design problems beyond individual classes
•Business metrics build the case — Velocity decline, bug rates, and onboarding friction provide stakeholder-friendly justification
•Framework-based evaluation ensures consistency — Scoring candidates across multiple dimensions prevents emotional or political decisions
•Not all inheritance is bad — The goal is to identify hierarchies where inheritance is actively harmful, not to eliminate inheritance entirely

What's Next

Now that you can identify refactoring candidates, the next page will walk you through the step-by-step process of actually performing the refactoring—transforming inheritance hierarchies into composition-based designs while maintaining system stability.

System Design (LLD)Refactoring from Inheritance to Composition

Refactoring from Inheritance to Composition

LevelAdvanced

Duration60 mins

TopicRefactoring from Inheritance to Composition

1 / 4

Identifying Refactoring Candidates

The Hidden Cost of Inherited Debt

What You Will Learn

Why Identification Matters

The cost of premature refactoring:

The cost of delayed refactoring:

The identification skill:

Goals of Accurate Identification

•Maximize ROI — Focus refactoring effort on hierarchies causing the most pain, not those that merely violate theoretical principles
•Minimize Risk — Identify candidates where refactoring can be done incrementally, reducing the blast radius of changes
•Build Consensus — Provide concrete evidence that justifies the investment, making it easier to align stakeholders
•Scope Appropriately — Understand the full extent of changes required before committing to a refactoring project

Code Smells Indicating Inheritance Problems

Smells vs. Symptoms

2.1 The Refused Bequest Smell

What it looks like: A subclass inherits methods or properties that it doesn't use, or worse, that it must actively disable or override with empty implementations.

refused_bequest_smell.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
// The Base Class - seems reasonable at first
abstract class Bird {
    protected String name;
    
    public Bird(String name) {
        this.name = name;
    }
    
    // All birds fly... right?
    public abstract void fly();
    
    public abstract void makeSound();
}
 
// Works perfectly for flying birds
class Eagle extends Bird {
    public Eagle() {
        super("Eagle");
    }
    
    @Override
    public void fly() {
        System.out.println("Eagle soars majestically through the sky");
    }
    
    @Override
    public void makeSound() {
        System.out.println("Screech!");
    }
}
 
// 🚨 REFUSED BEQUEST: Penguin must "refuse" the fly() inheritance
class Penguin extends Bird {
    public Penguin() {
        super("Penguin");
    }
    
    @Override
    public void fly() {
        // What do we do here?
        // Option 1: Throw an exception (breaks Liskov)
        throw new UnsupportedOperationException("Penguins cannot fly");
        
        // Option 2: Do nothing (misleading, violates interface contract)
        // return;
        
        // Option 3: Print a message (band-aid solution)
        // System.out.println("*waddles instead*");
    }
    
    @Override
    public void makeSound() {
        System.out.println("*penguin sounds*");
    }
    
    // Penguins have a capability that other birds don't
    public void swim() {
        System.out.println("Penguin swims gracefully");
    }
}
 
// Client code that now has landmines
class BirdSanctuary {
    public void releaseBird(Bird bird) {
        bird.fly();  // 💥 Explodes if bird is a Penguin
    }
}

2.2 The Parallel Inheritance Hierarchies Smell

What it looks like: Every time you create a new subclass in one hierarchy, you find yourself creating a corresponding subclass in another hierarchy.

parallel_hierarchies_smell.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
// 🚨 PARALLEL INHERITANCE HIERARCHIES
// Note how every Report subclass requires a matching Generator subclass
 
// Hierarchy 1: Reports
abstract class Report {
    abstract String getTitle();
    abstract Map<String, Object> getData();
}
 
class MonthlyReport extends Report {
    @Override String getTitle() { return "Monthly Report"; }
    @Override Map<String, Object> getData() { /* ... */ }
}
 
class QuarterlyReport extends Report {
    @Override String getTitle() { return "Quarterly Report"; }
    @Override Map<String, Object> getData() { /* ... */ }
}
 
class AnnualReport extends Report {
    @Override String getTitle() { return "Annual Report"; }
    @Override Map<String, Object> getData() { /* ... */ }
}
 
// Hierarchy 2: Generators (PARALLEL to Reports!)
abstract class ReportGenerator {
    abstract void generate(Report report);
}
 
class MonthlyReportGenerator extends ReportGenerator {
    @Override void generate(Report report) {
        // Can only work with MonthlyReport
        MonthlyReport mr = (MonthlyReport) report;  // 🚨 Cast required!
        // ... monthly-specific generation logic
    }
}
 
class QuarterlyReportGenerator extends ReportGenerator {
    @Override void generate(Report report) {
        QuarterlyReport qr = (QuarterlyReport) report;  // 🚨 Another cast!
        // ... quarterly-specific generation logic
    }
}
 
class AnnualReportGenerator extends ReportGenerator {
    @Override void generate(Report report) {
        AnnualReport ar = (AnnualReport) report;  // 🚨 Yet another cast!
        // ... annual-specific generation logic
    }
}
 
// Every new report type = TWO new classes
// New report type: ComplianceReport requires ComplianceReportGenerator
// The hierarchies MUST grow in parallel

2.3 The Speculative Generality Smell

What it looks like: Abstract classes or elaborate hierarchies exist "just in case" they're needed someday, but currently have only one concrete implementation.

2.4 The Shotgun Surgery Smell

What it looks like: Making a single conceptual change requires modifying many classes across the inheritance hierarchy.

Summary: Code Smells Indicating Inheritance Problems
Smell	Key Indicator	Severity	Refactoring Urgency
Refused Bequest	Subclasses override to disable functionality	High	Immediate—violates Liskov
Parallel Hierarchies	Adding one subclass requires adding another	High	High—coupling compounds
Speculative Generality	Abstract classes with single implementation	Medium	Low—simplify when touched
Shotgun Surgery	Small changes touch many hierarchy classes	High	High—indicates scattered responsibility

Structural Indicators

3.1 Deep Inheritance Hierarchies

The pattern: Class hierarchies that extend beyond 2-3 levels of depth.

Why it's problematic:

Cognitive load: Understanding a class requires understanding all ancestor classes
Fragile base class: Changes at any level can break descendants in unexpected ways
Rigidity: Deep hierarchies resist change because modifications cascade

Exception: Framework classes (like UI widget hierarchies) may legitimately be deeper, but business domain classes rarely need such depth.

deep_hierarchy_example.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// 🚨 DEEP HIERARCHY: 5 levels deep
// Understanding SpecialDiscountPremiumVIPCustomer requires
// understanding 4 ancestor classes
 
class Entity { }                                    // Level 1
    class User extends Entity { }                   // Level 2
        class Customer extends User { }             // Level 3
            class PremiumCustomer extends Customer { }        // Level 4
                class VIPCustomer extends PremiumCustomer { } // Level 5
                    // What if we need VIPWithSpecialDiscount?
                    class SpecialDiscountVIPCustomer extends VIPCustomer { } // Level 6!
 
// Problems:
// 1. Where does "apply discount logic" live?
// 2. How do you create a "Premium but not VIP" with special discounts?
// 3. What if VIP rules change? Do SpecialDiscountVIP customers inherit the change?
 
// The hierarchy encodes business rules in structure
// But business rules change, and structure is expensive to change

3.2 Wide Inheritance Hierarchies

The pattern: A single base class with many (10+) direct subclasses.

Why it's problematic:

Switch/case proliferation: Client code often ends up with giant switch statements based on type
Modification amplification: Changes to the base class interface affect all subclasses
Unclear abstraction: The base class often becomes a grab-bag of methods, some relevant to some subclasses but not others

What it suggests: The subclasses likely represent variations that should be modeled as composed behaviors rather than inherited types.

3.3 Diamond-Like Patterns (Without Multiple Inheritance)

The pattern: Even in single-inheritance languages, you see workarounds that effectively create diamond patterns—where a logical subclass would need to inherit from two incompatible parents.

How it manifests:

Utility classes or mixins that duplicate functionality across branches
Interfaces used to "simulate" the missing parent
Delegation that partially reimplements inherited behavior

Why it indicates composition need: If you're fighting to achieve multiple inheritance effects, composition would give you those effects naturally without the architectural contortions.

The Inheritance–Composition Boundary

3.4 Violation of the Liskov Substitution Principle (LSP)

The pattern: Client code that checks the specific type of objects before operating on them, or catches exceptions that indicate an object doesn't support an inherited method.

Detection techniques:

Search for instanceof checks in client code
Look for catch blocks that handle UnsupportedOperationException or similar
Find comments like "// This shouldn't happen for XYZ type"

Why it's serious: LSP violations indicate that the inheritance hierarchy is lying about substitutability. The type system promises something that runtime behavior doesn't deliver.

lsp_violation_detection.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
// 🚨 LSP VIOLATION INDICATORS IN CLIENT CODE
 
class PaymentProcessor {
    public void processPayment(Payment payment) {
        // Type checking is a red flag
        if (payment instanceof CashPayment) {
            // Cash doesn't need authorization
            processCashPayment((CashPayment) payment);
        } else if (payment instanceof CreditCardPayment) {
            // Credit cards need authorization
            authorizeThenProcess((CreditCardPayment) payment);
        } else if (payment instanceof CryptoPayment) {
            // Crypto has completely different flow
            processCryptoPayment((CryptoPayment) payment);
        }
        // 🚨 Every new payment type requires modifying this method
    }
}
 
// Also suspicious: exception handling that checks types
class OrderService {
    public void submitOrder(Order order) {
        try {
            order.validate();
        } catch (UnsupportedOperationException e) {
            // Some order types don't support validation?
            // This means Order.validate() is a broken contract
            if (order instanceof LegacyOrder) {
                // Just skip validation for legacy orders
                // 🚨 LSP violation: LegacyOrder isn't truly an Order
            }
        }
    }
}

Business and Operational Signals

Business Signals That Indicate Refactoring Need

•Feature Velocity Decline — New features in the affected area take 2-3x longer than similar features elsewhere. Sprint velocity has noticeably dropped.
•Escalating Bug Counts — Fix rates in the inheritance hierarchy lag behind the rest of the codebase. Fixes frequently introduce new bugs (regression rate).
•Onboarding Friction — New team members take significantly longer to become productive in code touching the hierarchy. The learning curve is disproportionately steep.
•Cross-Cutting Feature Requests — Business requests features that cut across the hierarchy ("all customer types need X") which require modifying every subclass.
•Reluctance to Touch the Code — Engineers actively avoid tasks involving the hierarchy. There's informal agreement that certain areas are "dangerous" to modify.

4.1 Measuring Feature Velocity Impact

To build a compelling case for refactoring, quantify the impact on delivery speed:

Method 1: Comparative Story Point Analysis

Compare estimated vs. actual story points for features in the affected area versus the overall codebase. A consistent 50%+ overrun in the affected area suggests structural problems.

Method 2: Lead Time Tracking

Measure how long features take from specification to production. If features touching the inheritance hierarchy consistently take 2-3x longer, that's concrete evidence.

Method 3: Change Failure Rate

Track how often changes to the hierarchy require hotfixes or rollbacks compared to changes elsewhere. A higher change failure rate indicates fragility.

Speaking the Language of Stakeholders

4.2 Operational Red Flags

Sometimes inheritance problems manifest in runtime behavior rather than development friction:

Memory overhead: Deep inheritance hierarchies can cause object bloat as each level adds fields. Monitor memory usage for objects in the hierarchy.

Performance cliffs: Polymorphic dispatch through deep hierarchies can cause cache misses. Profile before assuming this is an issue, but be aware of the possibility.

Configuration explosion: If you find yourself needing to configure behavior at multiple hierarchy levels with complex override rules, the hierarchy is fighting against the flexibility you need.

The Identification Framework

Refactoring Candidate Evaluation Framework
Dimension	Questions to Ask	Weight
Pain Level	How much active suffering is this causing? (blocked features, frequent bugs, team complaints)	High
Frequency of Change	How often does this hierarchy need modification? (Weekly = high priority)	High
Blast Radius	How much of the codebase depends on this hierarchy?	Medium
Refactoring Complexity	How difficult will the refactoring be? (scope, test coverage, team skill)	Medium
Strategic Importance	Does this affect systems that are critical to business priorities?	High
Alternatives	Are there workarounds that can defer the refactoring? At what cost?	Low

5.1 Applying the Framework: A Scoring Approach

For each candidate hierarchy, score these dimensions on a 1-5 scale:

Pain Level (1-5): 1 = minor annoyance, 5 = actively blocking work
Change Frequency (1-5): 1 = rarely touched, 5 = modified weekly
Blast Radius (1-5): 1 = isolated subsystem, 5 = touches everything
Complexity (1-5): 1 = straightforward, 5 = extremely complex (INVERT this score when prioritizing)
Strategic Importance (1-5): 1 = peripheral, 5 = core business function

Priority Score = (Pain × 2) + (Frequency × 2) + (Strategic × 1.5) + (Blast × 0.5) - Complexity

Higher scores indicate higher priority for refactoring. The complexity subtraction ensures you factor in the cost of the work, not just the benefit.

refactoring_priority_analysis.ts
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
// Practical Priority Analysis Template
 
interface RefactoringCandidate {
  name: string;
  painLevel: number;      // 1-5
  changeFrequency: number; // 1-5
  blastRadius: number;    // 1-5
  complexity: number;     // 1-5
  strategicImportance: number; // 1-5
}
 
function calculatePriority(candidate: RefactoringCandidate): number {
  return (
    (candidate.painLevel * 2) +
    (candidate.changeFrequency * 2) +
    (candidate.strategicImportance * 1.5) +
    (candidate.blastRadius * 0.5) -
    candidate.complexity
  );
}
 
// Example: Evaluate three candidate hierarchies
const candidates: RefactoringCandidate[] = [
  {
    name: "CustomerHierarchy (Entity → User → Customer → Premium → VIP)",
    painLevel: 4,           // Frequently causes bugs
    changeFrequency: 5,     // Modified almost weekly
    blastRadius: 4,         // Used throughout the system
    complexity: 4,          // Will require significant effort
    strategicImportance: 5, // Customer management is core business
  },
  {
    name: "ReportHierarchy (Report → Daily/Weekly/Monthly)",
    painLevel: 3,           // Annoying but manageable
    changeFrequency: 2,     // Rarely changed
    blastRadius: 2,         // Isolated to reporting module
    complexity: 2,          // Relatively simple refactor
    strategicImportance: 2, // Reporting is secondary function
  },
  {
    name: "PaymentHierarchy (Payment → Cash/Card/Crypto)",
    painLevel: 5,           // Blocking new payment integrations
    changeFrequency: 4,     // New payment types quarterly
    blastRadius: 3,         // Checkout flow only
    complexity: 3,          // Medium complexity
    strategicImportance: 5, // Revenue-critical
  },
];
 
// Calculate and sort by priority
const prioritized = candidates
  .map(c => ({ ...c, priority: calculatePriority(c) }))
  .sort((a, b) => b.priority - a.priority);
 
console.log("Refactoring Priorities:");
prioritized.forEach((c, i) => {
  console.log(`${i + 1}. ${c.name}: Priority Score = ${c.priority.toFixed(1)}`);
});
 
// Output:
// 1. PaymentHierarchy: Priority Score = 21.5
// 2. CustomerHierarchy: Priority Score = 20.5
// 3. ReportHierarchy: Priority Score = 9.0

Case Study: Identifying a Real Candidate

Let's walk through a realistic scenario of identifying a refactoring candidate in a production system.

Scenario: E-Commerce Notification System

6.1 Current State Analysis

The existing hierarchy looks like this:

notification_hierarchy.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
// Current Inheritance Hierarchy
 
abstract class Notification {
    protected String recipient;
    protected String content;
    protected Priority priority;
    
    public abstract void send();
    public abstract void validate();
    public abstract String formatContent();
}
 
// Email branch
class EmailNotification extends Notification {
    private String subject;
    private List<Attachment> attachments;
    
    @Override public void send() { /* SMTP logic */ }
    @Override public void validate() { /* email validation */ }
    @Override public String formatContent() { /* HTML formatting */ }
}
 
class MarketingEmailNotification extends EmailNotification {
    private String campaignId;
    private boolean trackOpens;
    // Adds marketing-specific tracking
}
 
class TransactionalEmailNotification extends EmailNotification {
    private String orderId;
    // Adds order-related context
}
 
// SMS branch
class SmsNotification extends Notification {
    private String phoneNumber;
    
    @Override public void send() { /* Twilio API */ }
    @Override public void validate() { /* phone validation */ }
    @Override public String formatContent() { /* 160 char limit */ }
}
 
class PromotionalSmsNotification extends SmsNotification {
    private String promoCode;
    // Must include opt-out language
}
 
// Push branch
class PushNotification extends Notification {
    private String deviceToken;
    private String deepLink;
    
    @Override public void send() { /* Firebase/APNs */ }
    @Override public void validate() { /* token validation */ }
    @Override public String formatContent() { /* structured payload */ }
}
 
// ... hierarchy continues for each notification type and channel

6.2 Observed Problems

Code Smell Evidence:

Parallel Hierarchy: Adding "transactional" notifications required TransactionalEmailNotification, TransactionalSmsNotification, and TransactionalPushNotification—three classes for one concept.
Refused Bequest: SmsNotification can't use the attachments capability that makes sense for email. Rich content formatting in the base class is ignored by SMS.
Shotgun Surgery: Adding GDPR compliance fields required modifying 12 notification classes instead of one place.

Structural Evidence:

Hierarchy is 3 levels deep and growing
15+ concrete notification classes
Base class has methods that some subclasses don't use

Business Evidence:

Adding a new notification channel (Slack) estimated at 4 weeks due to class explosion
New provider integrations (switching from Twilio to alternate SMS provider) blocked by tight coupling
Team avoids notification-related features in sprint planning

6.3 Identification Decision

Applying the scoring framework:

Dimension	Score	Rationale
Pain Level	4	Teams actively avoiding the code
Change Frequency	4	Multiple changes per month
Blast Radius	3	Core communication system
Complexity	4	Deep hierarchy, many integrations
Strategic Importance	4	Customer communication is vital

Priority Score = (4×2) + (4×2) + (4×1.5) + (3×0.5) - 4 = 8 + 8 + 6 + 1.5 - 4 = 19.5

Summary: Identifying Refactoring Candidates

We've established a comprehensive framework for identifying when inheritance-based designs should be refactored to composition. Let's consolidate the key takeaways:

Key Takeaways

•Code smells are signals, not mandates — Use them to trigger investigation, not automatic refactoring decisions
•Structural patterns reveal systemic issues — Deep hierarchies, wide hierarchies, and LSP violations indicate design problems beyond individual classes
•Business metrics build the case — Velocity decline, bug rates, and onboarding friction provide stakeholder-friendly justification
•Framework-based evaluation ensures consistency — Scoring candidates across multiple dimensions prevents emotional or political decisions
•Not all inheritance is bad — The goal is to identify hierarchies where inheritance is actively harmful, not to eliminate inheritance entirely

What's Next