System Design (LLD)Revisiting Inheritance Problems

Revisiting Inheritance Problems

LevelIntermediate

Duration60 mins

TopicRevisiting Inheritance Problems

3 / 4

Inheritance Hierarchy Rigidity

The Cement That Sets Too Fast

Software is supposed to be soft—malleable, adaptable, changeable. The very name implies flexibility. Yet inheritance hierarchies often become the hardest parts of a codebase to modify.

Every experienced engineer has encountered the phenomenon: what started as an elegant class hierarchy becomes a rigid structure where moving a method, extracting a class, or changing a relationship requires weeks of work and touches dozens of files. The hierarchy, designed to promote reuse, has become a cage that prevents evolution.

In this page, we'll examine why inheritance hierarchies inevitably become rigid, understand the mechanisms that create this rigidity, and recognize the patterns that accelerate it. This understanding is essential for knowing when to avoid inheritance altogether—and when the rigidity might be acceptable.

What You Will Learn

By the end of this page, you will understand why inheritance hierarchies resist change, how the IS-A relationship creates permanent structural commitments, why requirements evolution conflicts with inheritance design, and how to recognize hierarchies that are becoming dangerously rigid.

The Nature of Hierarchy Rigidity

Rigidity in software design refers to the difficulty of making changes. A rigid system is one where modifications require extensive updates across many components—where a simple conceptual change requires touching dozens of files and rerunning hundreds of tests.

Inheritance hierarchies exhibit a particular kind of rigidity we call structural rigidity. The structure itself—the relationships between classes—becomes fixed and resistant to change. This happens for several fundamental reasons:

Sources of Inheritance Rigidity

•IS-A Commitments Are Permanent — Once you declare that Employee IS-A Person, that relationship is baked into the type system. Changing it requires changing every piece of code that treats Employees as Persons.
•Hierarchies Embed Domain Assumptions — The structure of an inheritance hierarchy reflects a particular understanding of the problem domain. When that understanding changes, the structure must change too—but the structure resists change.
•Changes Cascade Both Ways — Modifying a parent class affects all descendants. Modifying a child class may require changes up the hierarchy. You're constrained in both directions.
•Shared State Creates Dependencies — When classes share protected fields up the hierarchy, they create mutual dependencies that make independent evolution impossible.
•Testing Couples to Structure — Tests often test the hierarchy structure (this IS-A that, calls super, etc.), making structural changes break tests even when behavior is correct.

The Irony of Reuse

Inheritance is promoted as a mechanism for code reuse. But the more classes share through inheritance, the more tightly coupled they become, and the harder it is to change any of them. High reuse leads to high rigidity.

The IS-A Lock-In

When you write class Dog extends Animal, you're making a permanent declaration: for the entire lifetime of your software, a Dog IS-A Animal. Every method that accepts an Animal can accept a Dog. Every collection of Animals can contain Dogs. The type system enforces this at compile time.

This seems reasonable—until requirements change.

Case Study: The Payment Hierarchy

Consider an e-commerce platform that started with a simple payment design:

PaymentV1.java
Year 1 Design
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
// Year 1: Simple, clean hierarchy
abstract class Payment {
    abstract void process();
    abstract void refund();
}
 
class CreditCardPayment extends Payment {
    private String cardNumber;
    private String cvv;
    
    void process() { /* charge card */ }
    void refund() { /* credit back */ }
}
 
class PayPalPayment extends Payment {
    private String paypalEmail;
    
    void process() { /* call PayPal API */ }
    void refund() { /* call PayPal refund API */ }
}
 
// Usage everywhere:
void checkout(Payment payment) {
    payment.process();
}

This works beautifully. But over years, requirements evolve:

RequirementsEvolution.txt

Requirements Timeline

Year 2: Add subscription payments (recurring)
        → Some payments can recur, others can't
        → Does this belong in Payment base class?
 
Year 3: Add crypto payments (no refunds possible)
        → CryptoPayment can't implement refund()
        → Violates Liskov Substitution Principle?
 
Year 4: Add "pay later" (deferred processing)
        → Processing isn't immediate
        → State machine needed, doesn't fit current model
 
Year 5: Split payments (part card, part gift card)
        → One "payment" involves two payment methods
        → Breaks the entire single-inheritance model
 
Year 6: Cross-border payments (different regulations)
        → Same payment type behaves differently by region
        → Is this a new class or a parameter?

The Lock-In Problem

Each requirement creates pressure on the hierarchy, but the hierarchy resists change:

Lock-In Scenarios in the Payment Hierarchy
Requirement	Naive Solution	Lock-In Pain	What You Really Want
Recurring payments	Add `isRecurring()` to Payment base	All 15 payment types now need this method	Separate `Subscription` capability
No-refund payments	CryptoPayment throws on refund()	Breaks LSP, clients must check type	Separate `Refundable` interface
Deferred processing	Add state field to Payment	Simple payments don't need states	`DeferredPayment` wrapper or strategy
Split payments	CompositePayment with multiple children	Doesn't fit IS-A model	Composition from the start
Regional variations	RegionalCreditCardPayment extends CreditCard	Hierarchy explosion: 15 types × 50 regions	Strategy pattern for regional rules

The IS-A Escape Hatch Doesn't Exist

You cannot say 'CryptoPayment IS-A Payment except for refunds.' IS-A is total and unconditional. Once declared, the subclass must fulfill the entire parent contract—including methods that don't make sense for it.

Hierarchy Depth Amplifies Rigidity

The deeper an inheritance hierarchy, the more rigid it becomes. Each level in the hierarchy adds another set of commitments that constrain the levels below and above it.

The Multiplication Effect

Consider how changes propagate in hierarchies of different depths:

HierarchyDepth.txt

Depth Analysis

Shallow Hierarchy (2 levels):
 
    Animal
     ├── Dog
     └── Cat
     
Change to Animal affects: 2 classes
Total coupling: Low
Refactoring effort: Hours
 
---
 
Deep Hierarchy (5 levels):
 
    Entity
     └── LivingThing
          └── Animal
               └── Mammal
                    └── Canine
                         └── Dog
 
Change to Animal affects: 3 classes (Mammal, Canine, Dog)
Change to Entity affects: 5 classes (everything)
Total coupling: Very High
Refactoring effort: Days to Weeks

The Middle Layer Problem

Middle layers in deep hierarchies are especially problematic. They're constrained by both their parent (must extend correctly) and their children (must not break descendant assumptions).

Consider what happens when you want to change Mammal in the deep hierarchy:

Upward constraints: Mammal must remain a valid Animal (can't remove inherited methods)
Downward constraints: Canine and Dog depend on Mammal's implementation details
Sibling constraints: If Cat also extends Animal, Animal changes must work for both branches
Interface constraints: External code depends on Mammal as a type

The middle layer is locked in from all sides.

The Rule of Two

Many experienced developers follow an informal 'rule of two': inherit at most two levels deep. Beyond two levels, the rigidity typically outweighs the benefits. If you find yourself creating a third level, consider whether composition would work better.

Real-World Deep Hierarchy: Java AWT/Swing

Java's GUI framework demonstrates deep hierarchy rigidity in practice:

SwingHierarchy.txt

AWT/Swing Hierarchy

java.lang.Object
 └── java.awt.Component
      └── java.awt.Container
           └── javax.swing.JComponent
                └── javax.swing.JPanel
                     └── YourCustomPanel
                    
Each level adds state, behavior, and constraints:
- Object: equals, hashCode, toString committed
- Component: painting, layout, events committed
- Container: child management committed
- JComponent: double buffering, borders committed
- JPanel: layout management committed
 
Result:
- Simple changes require understanding 5+ classes
- Performance optimizations often impossible
- Modern features (hardware acceleration) require workarounds
- Framework has been largely unmaintainable since 2000s

The Width Problem: Too Many Subclasses

Rigidity doesn't only come from depth—it also comes from width. When a parent class has many subclasses, any change to the parent must work for all of them.

The Fan-Out Effect

WidthProblem.txt

Hierarchy Width

                        Shape (abstract)
                           │
    ┌──────────┬──────────┼──────────┬──────────┐
    │          │          │          │          │
  Circle    Square    Triangle   Polygon   Ellipse
                           │
               ┌───────────┼───────────┐
               │           │           │
         Equilateral   Isosceles   Scalene
 
Width at Shape level: 5 direct subclasses
Width at Triangle level: 3 direct subclasses
 
Any change to Shape must:
- Not break Circle, Square, Triangle, Polygon, Ellipse
- Not break the 3 Triangle subclasses (transitively)
- Work with any future shapes that might be added
- Maintain backward compatibility with existing code

The Lowest Common Denominator Effect

When a parent has many diverse subclasses, it's forced toward the lowest common denominator—only those characteristics that apply to ALL subclasses can live in the parent.

This leads to one of two outcomes:

Anemic Parent Classes — The parent does almost nothing, pushing all behavior to subclasses (defeating the purpose of inheritance)
Inappropriate Inherited Behavior — The parent includes behavior that doesn't apply to all subclasses, requiring overrides that do nothing or throw exceptions

AnemicParent.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// Anemic parent - almost useless
abstract class Shape {
    // All shapes have... what exactly?
    // Different shapes have vastly 
    // different properties
    
    abstract double area();
    // That's about all they share
}
 
// Each subclass reimplements everything
class Circle extends Shape {
    private double radius;
    // Own: circumference, diameter, etc.
}
 
class Polygon extends Shape {
    private List<Point> vertices;
    // Own: perimeter, sides, angles, etc.
}
 
// The inheritance adds almost nothing!

InappropriateBehavior.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// Parent with inappropriate behavior
abstract class Shape {
    abstract double area();
    abstract double perimeter();
    abstract int numberOfSides();
    abstract List<Point> vertices();
}
 
// Circle has to override inappropriately
class Circle extends Shape {
    int numberOfSides() {
        return 0; // or infinity? or throw?
    }
    
    List<Point> vertices() {
        return Collections.emptyList();
        // A circle has no vertices!
        // But must implement...
    }
}
 
// The hierarchy imposes wrong contracts

The Hierarchy Catch-22

Put too much in the parent, and some subclasses must override inappropriately. Put too little in the parent, and inheritance provides no value. Wide hierarchies often fall into one trap or the other.

Requirements Change vs. Hierarchy Stability

Inheritance hierarchies encode a snapshot of understanding—how the problem domain was understood at the time of design. But requirements change, often in ways that contradict the original structure.

The Fundamental Tension

Requirements Evolution vs. Inheritance Design
Domain Evolution	Hierarchy Assumption	Conflict
Objects gain new behaviors	Class structure is stable	New behaviors don't fit existing hierarchy
Cross-cutting concerns emerge	Behavior follows IS-A lines	New concern doesn't align with inheritance
Categories become fuzzy	IS-A is crisp and total	Real-world objects don't cleanly categorize
Behaviors become optional	Inheritance is fixed at design time	Can't add/remove capabilities dynamically
New combinations needed	Single inheritance (usually)	Need behaviors from multiple parents

Example: The User Type Hierarchy

A common pattern that frequently runs into requirements conflicts:

UserHierarchy.java
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
// Initial design: Users have distinct types
abstract class User {
    protected String email;
    protected String name;
    
    abstract Set<Permission> permissions();
}
 
class AdminUser extends User {
    Set<Permission> permissions() {
        return Set.of(READ, WRITE, DELETE, ADMIN);
    }
}
 
class RegularUser extends User {
    Set<Permission> permissions() {
        return Set.of(READ, WRITE);
    }
}
 
class GuestUser extends User {
    Set<Permission> permissions() {
        return Set.of(READ);
    }
}

Then requirements change:

NewRequirements.txt

New Requirements

Requirement 1: Users can have custom permission sets
→ The fixed permission sets in subclasses don't work
→ Should permissions come from database, not class type?
 
Requirement 2: A user can be Admin in one context, Regular in another
→ User type depends on context (team, project, etc.)
→ IS-A relationship is not stable across contexts!
 
Requirement 3: Users can be promoted/demoted at runtime
→ Objects can't change their class at runtime
→ An AdminUser can't become a RegularUser without recreation
 
Requirement 4: "Service accounts" (not human users)
→ ServiceAccount IS-A User? Shares some behavior but not all
→ ServiceAccounts don't have names in the same sense
→ Hierarchy doesn't accommodate non-human actors

The Alternative Approach

With composition, these requirements are easy to accommodate:

UserComposition.java
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
// Composition approach: flexible from the start
class User {
    private String email;
    private String name;
    private PermissionProvider permissionProvider;  // Injected
    
    User(String email, String name, PermissionProvider provider) {
        this.email = email;
        this.name = name;
        this.permissionProvider = provider;
    }
    
    Set<Permission> getPermissions(Context context) {
        return permissionProvider.permissionsFor(this, context);
    }
    
    void setPermissionProvider(PermissionProvider provider) {
        this.permissionProvider = provider;  // Can change at runtime!
    }
}
 
// Now:
// - Permissions can come from database, roles, context
// - Same user can have different permissions in different contexts
// - Permission provider can change (promotion/demotion)
// - Service accounts just use a different PermissionProvider

Composition Aligns with Change

Composition separates 'what varies' into injectable components. When requirements change, you add new implementations or swap components—without restructuring the core classes. This aligns with how requirements actually evolve.

The Refactoring Trap

One of the most frustrating aspects of hierarchy rigidity is that it makes refactoring exponentially harder. Techniques that work well for flat class structures become problematic when inheritance is involved.

Common Refactoring Challenges

Refactoring Operations and Inheritance Complications
Refactoring	Without Inheritance	With Inheritance
Rename Method	Rename in class, update callers	Must check: all subclasses, super calls, overrides, polymorphic references
Extract Class	Move fields and methods to new class	Which hierarchy level owns them? What about protected access? Subclass dependencies?
Move Method	Move to related class	Is it inherited? Overridden? Called from other levels?
Change Signature	Update callers	Must update all overrides. May break override relationship.
Introduce Parameter Object	Create object, update callers	All constructors in hierarchy must change. super() calls affected.
Pull Up Method	Move to parent	Do all subclasses want this? Is behavior truly common?
Push Down Method	Move to subclass	Which subclasses need it? What replaces it in parent?

Case Study: Extracting a Class from a Hierarchy

One of the most valuable refactorings—extracting a cohesive set of responsibilities into a new class—becomes complex with inheritance:

ExtractClass.java
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
// Before: Responsibilities tangled in hierarchy
abstract class Order {
    protected List<Item> items;
    protected Address shippingAddress;
    protected PaymentInfo payment;
    
    // Shipping logic mixed in
    protected double calculateShipping() {
        // Complex shipping calculation
    }
    
    protected void validateShipping() {
        // Shipping validation
    }
}
 
class OnlineOrder extends Order {
    @Override
    protected double calculateShipping() {
        double base = super.calculateShipping();
        return base * getOnlineDiscount();
    }
}
 
class StoreOrder extends Order {
    @Override
    protected double calculateShipping() {
        if (isPickup()) return 0;
        return super.calculateShipping();
    }
}

You want to extract shipping logic into a ShippingCalculator class. But:

Complications with Extraction

•calculateShipping() is protected — subclasses depend on this access level
•Subclasses override it — extraction breaks the override chain
•Subclasses call super.calculateShipping() — these calls must be rewired
•shippingAddress is accessed — extraction requires passing it or the calculator knowing about Orders
•Other methods in the hierarchy might call calculateShipping() — must update all
•Tests might assert on calculateShipping() behavior at each level — tests break

What Should Be Simple Becomes Complex

The extraction that should take 30 minutes turns into a multi-day effort:

Trace all uses of shipping methods across hierarchy
Identify which subclass behaviors must be preserved
Design new ShippingCalculator with strategy variants for each order type
Update all Order constructors to accept ShippingCalculator
Convert all overrides to strategy implementations
Update all tests
Ensure no subtle behavioral changes

Many teams give up and leave the code tangled—adding to technical debt.

Inheritance Penalizes Change

Every refactoring in a hierarchy requires more analysis, carries more risk, and affects more code than the same refactoring in a flat or composed structure. This penalty compounds over time, making large refactorings practically impossible.

Rigidity Across Version and Package Boundaries

Hierarchy rigidity becomes especially problematic when inheritance crosses version or package boundaries—when the parent class is in a library or module that you don't control.

The Library Inheritance Problem

LibraryInheritance.txt

Scenario

Your Code (version controlled by you):
└── MyApp
    └── CustomButton extends JButton  (Swing library)
    
Library (version controlled by Oracle/OpenJDK):
└── javax.swing
    └── JButton extends AbstractButton extends JComponent extends ...
 
Problems:
1. Library can change in minor versions, breaking your subclass
2. You can't modify JButton to add protected hooks you need
3. If JButton behavior changes, your override might not work
4. Library might mark JButton as final in future version
5. No coordination between your team and library maintainers

The Multi-Team Hierarchy Problem

Even within an organization, inheritance across team boundaries creates coordination overhead:

Cross-Team Inheritance Challenges
Scenario	Coordination Required	Practical Impact
Team A owns `Account` base class	Any change to Account must be reviewed by all teams using Account subclasses	Changes slow to 2-3 week cycles
Team B creates `PremiumAccount extends Account`	Team B needs to understand Account internals	Team B's velocity depends on Team A's documentation
Team A wants to optimize Account	Must verify all subclasses still work	Often impossible to verify; optimization abandoned
Team C needs feature that Team B has	Can't inherit from PremiumAccount (single inheritance)	Code duplication or complex workarounds
Breaking change needed in Account	All teams must update simultaneously	Often requires multi-sprint coordination

Microservice Implications

In microservice architectures, shared libraries with inheritance hierarchies create coupling that defeats the purpose of service independence:

MicroserviceCoupling.txt

Coupling Diagram

Shared Library: common-models.jar
└── BaseEntity (abstract)
    ├── Order (extended by order-service)
    ├── Product (extended by catalog-service)
    └── Customer (extended by customer-service)
 
Result:
- All 3 services depend on common-models version
- Change to BaseEntity requires all services to upgrade
- Services cannot deploy independently
- "Microservices" are effectively a distributed monolith
 
Better Approach:
- Each service owns its own models
- Share contracts (interfaces, APIs), not implementations
- No cross-service inheritance

Inheritance Undermines Modularity

Inheritance that crosses module or service boundaries undermines the independence those boundaries are meant to provide. The tight coupling of inheritance negates the loose coupling that makes modular systems maintainable.

Recognizing Rigidity Before It's Too Late

The best time to address hierarchy rigidity is before it becomes severe. Here are warning signs that a hierarchy is becoming dangerously rigid:

Warning Signs of Hierarchy Rigidity

•"Can't move that without breaking everything" — Developers avoid refactoring hierarchy components because impact is too large.
•Feature requests require new classes — Every new variation requires a new subclass instead of configuration or composition.
•Protected fields proliferate — More and more state is shared across the hierarchy through protected fields.
•Methods have if/else on type — Code checks instanceof to handle different subclass types, indicating the polymorphism isn't working.
•Super calls grow complex — Overriding methods have complex logic around when and how to call super.
•Common changes touch many files — A simple change requires modifications across multiple levels of the hierarchy.
•Tests specify hierarchy structure — Tests assert that class A extends B, rather than behavior.
•New developers struggle with hierarchy — Onboarding requires extensive study of the class structure.
•'It would be easier to rewrite' — Developers suggest starting over rather than modifying the existing hierarchy.

Quantifying Rigidity

Some metrics can help identify problematic hierarchies:

Metric	Concerning Value	What It Indicates
Depth of Inheritance	> 3 levels	Middle layers are likely trapped
Number of Subclasses	> 5 per parent	Parent changes affect too many classes
Protected Members	> 3 per class	Excessive shared state
Override Ratio	> 50% of methods overridden	Subclasses don't truly specialize
Super Call Complexity	> 2 super calls in one method	Complex parent dependency
Cross-Package Inheritance	Any	Coupling across module boundaries

Prevention Is Easier Than Cure

Once a hierarchy is deep, wide, and relied upon by many clients, refactoring to composition is extremely costly. The time to question inheritance is at design time—before the first subclass is created.

Summary: The Rigidity Reality

Inheritance hierarchies become rigid because of fundamental properties of the inheritance mechanism—not because of poor implementation. Let's consolidate the key lessons:

Key Takeaways

•IS-A relationships are permanent — Once declared, inheritance cannot be undone without major restructuring.
•Depth multiplies rigidity — Each level in a hierarchy adds constraints on all other levels.
•Width imposes lowest common denominator — Many subclasses force parents toward minimal or inappropriate abstractions.
•Requirements evolution conflicts with structural stability — The domain changes; the hierarchy resists change.
•Refactoring becomes exponentially harder — Standard refactoring techniques carry more risk and complexity in hierarchies.
•Cross-boundary inheritance is especially dangerous — Inheritance across packages, modules, or teams creates coordination overhead that defeats modularity.
•Recognize warning signs early — Identifying rigidity before it's severe allows for course correction.

What's Next

Having examined tight coupling, the fragile base class problem, and hierarchy rigidity, we've built a comprehensive understanding of inheritance's limitations. In the final page of this module, we'll synthesize these problems and explore why they create a compelling need for alternatives—setting the stage for our study of composition as the preferred approach.

Page Complete

You now understand why inheritance hierarchies become rigid and resist change. This rigidity is not a flaw in your design—it's inherent to the inheritance mechanism itself. Armed with this knowledge, you can make informed decisions about when the rigidity is acceptable and when alternatives are preferable.

3 / 4

Loading learning content...

System Design (LLD)Revisiting Inheritance Problems

Revisiting Inheritance Problems

LevelIntermediate

Duration60 mins

TopicRevisiting Inheritance Problems

3 / 4

Inheritance Hierarchy Rigidity

The Cement That Sets Too Fast

Software is supposed to be soft—malleable, adaptable, changeable. The very name implies flexibility. Yet inheritance hierarchies often become the hardest parts of a codebase to modify.

What You Will Learn

The Nature of Hierarchy Rigidity

Sources of Inheritance Rigidity

•IS-A Commitments Are Permanent — Once you declare that Employee IS-A Person, that relationship is baked into the type system. Changing it requires changing every piece of code that treats Employees as Persons.
•Hierarchies Embed Domain Assumptions — The structure of an inheritance hierarchy reflects a particular understanding of the problem domain. When that understanding changes, the structure must change too—but the structure resists change.
•Changes Cascade Both Ways — Modifying a parent class affects all descendants. Modifying a child class may require changes up the hierarchy. You're constrained in both directions.
•Shared State Creates Dependencies — When classes share protected fields up the hierarchy, they create mutual dependencies that make independent evolution impossible.
•Testing Couples to Structure — Tests often test the hierarchy structure (this IS-A that, calls super, etc.), making structural changes break tests even when behavior is correct.

The Irony of Reuse

The IS-A Lock-In

This seems reasonable—until requirements change.

Case Study: The Payment Hierarchy

Consider an e-commerce platform that started with a simple payment design:

PaymentV1.java
Year 1 Design
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
// Year 1: Simple, clean hierarchy
abstract class Payment {
    abstract void process();
    abstract void refund();
}
 
class CreditCardPayment extends Payment {
    private String cardNumber;
    private String cvv;
    
    void process() { /* charge card */ }
    void refund() { /* credit back */ }
}
 
class PayPalPayment extends Payment {
    private String paypalEmail;
    
    void process() { /* call PayPal API */ }
    void refund() { /* call PayPal refund API */ }
}
 
// Usage everywhere:
void checkout(Payment payment) {
    payment.process();
}

This works beautifully. But over years, requirements evolve:

RequirementsEvolution.txt

Requirements Timeline

Year 2: Add subscription payments (recurring)
        → Some payments can recur, others can't
        → Does this belong in Payment base class?
 
Year 3: Add crypto payments (no refunds possible)
        → CryptoPayment can't implement refund()
        → Violates Liskov Substitution Principle?
 
Year 4: Add "pay later" (deferred processing)
        → Processing isn't immediate
        → State machine needed, doesn't fit current model
 
Year 5: Split payments (part card, part gift card)
        → One "payment" involves two payment methods
        → Breaks the entire single-inheritance model
 
Year 6: Cross-border payments (different regulations)
        → Same payment type behaves differently by region
        → Is this a new class or a parameter?

The Lock-In Problem

Each requirement creates pressure on the hierarchy, but the hierarchy resists change:

Lock-In Scenarios in the Payment Hierarchy
Requirement	Naive Solution	Lock-In Pain	What You Really Want
Recurring payments	Add `isRecurring()` to Payment base	All 15 payment types now need this method	Separate `Subscription` capability
No-refund payments	CryptoPayment throws on refund()	Breaks LSP, clients must check type	Separate `Refundable` interface
Deferred processing	Add state field to Payment	Simple payments don't need states	`DeferredPayment` wrapper or strategy
Split payments	CompositePayment with multiple children	Doesn't fit IS-A model	Composition from the start
Regional variations	RegionalCreditCardPayment extends CreditCard	Hierarchy explosion: 15 types × 50 regions	Strategy pattern for regional rules

The IS-A Escape Hatch Doesn't Exist

Hierarchy Depth Amplifies Rigidity

The deeper an inheritance hierarchy, the more rigid it becomes. Each level in the hierarchy adds another set of commitments that constrain the levels below and above it.

The Multiplication Effect

Consider how changes propagate in hierarchies of different depths:

HierarchyDepth.txt

Depth Analysis

Shallow Hierarchy (2 levels):
 
    Animal
     ├── Dog
     └── Cat
     
Change to Animal affects: 2 classes
Total coupling: Low
Refactoring effort: Hours
 
---
 
Deep Hierarchy (5 levels):
 
    Entity
     └── LivingThing
          └── Animal
               └── Mammal
                    └── Canine
                         └── Dog
 
Change to Animal affects: 3 classes (Mammal, Canine, Dog)
Change to Entity affects: 5 classes (everything)
Total coupling: Very High
Refactoring effort: Days to Weeks

The Middle Layer Problem

Middle layers in deep hierarchies are especially problematic. They're constrained by both their parent (must extend correctly) and their children (must not break descendant assumptions).

Consider what happens when you want to change Mammal in the deep hierarchy:

Upward constraints: Mammal must remain a valid Animal (can't remove inherited methods)
Downward constraints: Canine and Dog depend on Mammal's implementation details
Sibling constraints: If Cat also extends Animal, Animal changes must work for both branches
Interface constraints: External code depends on Mammal as a type

The middle layer is locked in from all sides.

The Rule of Two

Real-World Deep Hierarchy: Java AWT/Swing

Java's GUI framework demonstrates deep hierarchy rigidity in practice:

SwingHierarchy.txt

AWT/Swing Hierarchy

java.lang.Object
 └── java.awt.Component
      └── java.awt.Container
           └── javax.swing.JComponent
                └── javax.swing.JPanel
                     └── YourCustomPanel
                    
Each level adds state, behavior, and constraints:
- Object: equals, hashCode, toString committed
- Component: painting, layout, events committed
- Container: child management committed
- JComponent: double buffering, borders committed
- JPanel: layout management committed
 
Result:
- Simple changes require understanding 5+ classes
- Performance optimizations often impossible
- Modern features (hardware acceleration) require workarounds
- Framework has been largely unmaintainable since 2000s

The Width Problem: Too Many Subclasses

Rigidity doesn't only come from depth—it also comes from width. When a parent class has many subclasses, any change to the parent must work for all of them.

The Fan-Out Effect

WidthProblem.txt

Hierarchy Width

                        Shape (abstract)
                           │
    ┌──────────┬──────────┼──────────┬──────────┐
    │          │          │          │          │
  Circle    Square    Triangle   Polygon   Ellipse
                           │
               ┌───────────┼───────────┐
               │           │           │
         Equilateral   Isosceles   Scalene
 
Width at Shape level: 5 direct subclasses
Width at Triangle level: 3 direct subclasses
 
Any change to Shape must:
- Not break Circle, Square, Triangle, Polygon, Ellipse
- Not break the 3 Triangle subclasses (transitively)
- Work with any future shapes that might be added
- Maintain backward compatibility with existing code

The Lowest Common Denominator Effect

When a parent has many diverse subclasses, it's forced toward the lowest common denominator—only those characteristics that apply to ALL subclasses can live in the parent.

This leads to one of two outcomes:

Anemic Parent Classes — The parent does almost nothing, pushing all behavior to subclasses (defeating the purpose of inheritance)
Inappropriate Inherited Behavior — The parent includes behavior that doesn't apply to all subclasses, requiring overrides that do nothing or throw exceptions

AnemicParent.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// Anemic parent - almost useless
abstract class Shape {
    // All shapes have... what exactly?
    // Different shapes have vastly 
    // different properties
    
    abstract double area();
    // That's about all they share
}
 
// Each subclass reimplements everything
class Circle extends Shape {
    private double radius;
    // Own: circumference, diameter, etc.
}
 
class Polygon extends Shape {
    private List<Point> vertices;
    // Own: perimeter, sides, angles, etc.
}
 
// The inheritance adds almost nothing!

InappropriateBehavior.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// Parent with inappropriate behavior
abstract class Shape {
    abstract double area();
    abstract double perimeter();
    abstract int numberOfSides();
    abstract List<Point> vertices();
}
 
// Circle has to override inappropriately
class Circle extends Shape {
    int numberOfSides() {
        return 0; // or infinity? or throw?
    }
    
    List<Point> vertices() {
        return Collections.emptyList();
        // A circle has no vertices!
        // But must implement...
    }
}
 
// The hierarchy imposes wrong contracts

The Hierarchy Catch-22

Put too much in the parent, and some subclasses must override inappropriately. Put too little in the parent, and inheritance provides no value. Wide hierarchies often fall into one trap or the other.

Requirements Change vs. Hierarchy Stability

The Fundamental Tension

Requirements Evolution vs. Inheritance Design
Domain Evolution	Hierarchy Assumption	Conflict
Objects gain new behaviors	Class structure is stable	New behaviors don't fit existing hierarchy
Cross-cutting concerns emerge	Behavior follows IS-A lines	New concern doesn't align with inheritance
Categories become fuzzy	IS-A is crisp and total	Real-world objects don't cleanly categorize
Behaviors become optional	Inheritance is fixed at design time	Can't add/remove capabilities dynamically
New combinations needed	Single inheritance (usually)	Need behaviors from multiple parents

Example: The User Type Hierarchy

A common pattern that frequently runs into requirements conflicts:

UserHierarchy.java
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
// Initial design: Users have distinct types
abstract class User {
    protected String email;
    protected String name;
    
    abstract Set<Permission> permissions();
}
 
class AdminUser extends User {
    Set<Permission> permissions() {
        return Set.of(READ, WRITE, DELETE, ADMIN);
    }
}
 
class RegularUser extends User {
    Set<Permission> permissions() {
        return Set.of(READ, WRITE);
    }
}
 
class GuestUser extends User {
    Set<Permission> permissions() {
        return Set.of(READ);
    }
}

Then requirements change:

NewRequirements.txt

New Requirements

Requirement 1: Users can have custom permission sets
→ The fixed permission sets in subclasses don't work
→ Should permissions come from database, not class type?
 
Requirement 2: A user can be Admin in one context, Regular in another
→ User type depends on context (team, project, etc.)
→ IS-A relationship is not stable across contexts!
 
Requirement 3: Users can be promoted/demoted at runtime
→ Objects can't change their class at runtime
→ An AdminUser can't become a RegularUser without recreation
 
Requirement 4: "Service accounts" (not human users)
→ ServiceAccount IS-A User? Shares some behavior but not all
→ ServiceAccounts don't have names in the same sense
→ Hierarchy doesn't accommodate non-human actors

The Alternative Approach

With composition, these requirements are easy to accommodate:

UserComposition.java
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
// Composition approach: flexible from the start
class User {
    private String email;
    private String name;
    private PermissionProvider permissionProvider;  // Injected
    
    User(String email, String name, PermissionProvider provider) {
        this.email = email;
        this.name = name;
        this.permissionProvider = provider;
    }
    
    Set<Permission> getPermissions(Context context) {
        return permissionProvider.permissionsFor(this, context);
    }
    
    void setPermissionProvider(PermissionProvider provider) {
        this.permissionProvider = provider;  // Can change at runtime!
    }
}
 
// Now:
// - Permissions can come from database, roles, context
// - Same user can have different permissions in different contexts
// - Permission provider can change (promotion/demotion)
// - Service accounts just use a different PermissionProvider

Composition Aligns with Change

The Refactoring Trap

Common Refactoring Challenges

Refactoring Operations and Inheritance Complications
Refactoring	Without Inheritance	With Inheritance
Rename Method	Rename in class, update callers	Must check: all subclasses, super calls, overrides, polymorphic references
Extract Class	Move fields and methods to new class	Which hierarchy level owns them? What about protected access? Subclass dependencies?
Move Method	Move to related class	Is it inherited? Overridden? Called from other levels?
Change Signature	Update callers	Must update all overrides. May break override relationship.
Introduce Parameter Object	Create object, update callers	All constructors in hierarchy must change. super() calls affected.
Pull Up Method	Move to parent	Do all subclasses want this? Is behavior truly common?
Push Down Method	Move to subclass	Which subclasses need it? What replaces it in parent?

Case Study: Extracting a Class from a Hierarchy

One of the most valuable refactorings—extracting a cohesive set of responsibilities into a new class—becomes complex with inheritance:

ExtractClass.java
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
// Before: Responsibilities tangled in hierarchy
abstract class Order {
    protected List<Item> items;
    protected Address shippingAddress;
    protected PaymentInfo payment;
    
    // Shipping logic mixed in
    protected double calculateShipping() {
        // Complex shipping calculation
    }
    
    protected void validateShipping() {
        // Shipping validation
    }
}
 
class OnlineOrder extends Order {
    @Override
    protected double calculateShipping() {
        double base = super.calculateShipping();
        return base * getOnlineDiscount();
    }
}
 
class StoreOrder extends Order {
    @Override
    protected double calculateShipping() {
        if (isPickup()) return 0;
        return super.calculateShipping();
    }
}

You want to extract shipping logic into a ShippingCalculator class. But:

Complications with Extraction

•calculateShipping() is protected — subclasses depend on this access level
•Subclasses override it — extraction breaks the override chain
•Subclasses call super.calculateShipping() — these calls must be rewired
•shippingAddress is accessed — extraction requires passing it or the calculator knowing about Orders
•Other methods in the hierarchy might call calculateShipping() — must update all
•Tests might assert on calculateShipping() behavior at each level — tests break

What Should Be Simple Becomes Complex

The extraction that should take 30 minutes turns into a multi-day effort:

Trace all uses of shipping methods across hierarchy
Identify which subclass behaviors must be preserved
Design new ShippingCalculator with strategy variants for each order type
Update all Order constructors to accept ShippingCalculator
Convert all overrides to strategy implementations
Update all tests
Ensure no subtle behavioral changes

Many teams give up and leave the code tangled—adding to technical debt.

Inheritance Penalizes Change

Rigidity Across Version and Package Boundaries

Hierarchy rigidity becomes especially problematic when inheritance crosses version or package boundaries—when the parent class is in a library or module that you don't control.

The Library Inheritance Problem

LibraryInheritance.txt

Scenario

Your Code (version controlled by you):
└── MyApp
    └── CustomButton extends JButton  (Swing library)
    
Library (version controlled by Oracle/OpenJDK):
└── javax.swing
    └── JButton extends AbstractButton extends JComponent extends ...
 
Problems:
1. Library can change in minor versions, breaking your subclass
2. You can't modify JButton to add protected hooks you need
3. If JButton behavior changes, your override might not work
4. Library might mark JButton as final in future version
5. No coordination between your team and library maintainers

The Multi-Team Hierarchy Problem

Even within an organization, inheritance across team boundaries creates coordination overhead:

Cross-Team Inheritance Challenges
Scenario	Coordination Required	Practical Impact
Team A owns `Account` base class	Any change to Account must be reviewed by all teams using Account subclasses	Changes slow to 2-3 week cycles
Team B creates `PremiumAccount extends Account`	Team B needs to understand Account internals	Team B's velocity depends on Team A's documentation
Team A wants to optimize Account	Must verify all subclasses still work	Often impossible to verify; optimization abandoned
Team C needs feature that Team B has	Can't inherit from PremiumAccount (single inheritance)	Code duplication or complex workarounds
Breaking change needed in Account	All teams must update simultaneously	Often requires multi-sprint coordination

Microservice Implications

In microservice architectures, shared libraries with inheritance hierarchies create coupling that defeats the purpose of service independence:

MicroserviceCoupling.txt

Coupling Diagram

Shared Library: common-models.jar
└── BaseEntity (abstract)
    ├── Order (extended by order-service)
    ├── Product (extended by catalog-service)
    └── Customer (extended by customer-service)
 
Result:
- All 3 services depend on common-models version
- Change to BaseEntity requires all services to upgrade
- Services cannot deploy independently
- "Microservices" are effectively a distributed monolith
 
Better Approach:
- Each service owns its own models
- Share contracts (interfaces, APIs), not implementations
- No cross-service inheritance

Inheritance Undermines Modularity

Recognizing Rigidity Before It's Too Late

The best time to address hierarchy rigidity is before it becomes severe. Here are warning signs that a hierarchy is becoming dangerously rigid:

Warning Signs of Hierarchy Rigidity

•"Can't move that without breaking everything" — Developers avoid refactoring hierarchy components because impact is too large.
•Feature requests require new classes — Every new variation requires a new subclass instead of configuration or composition.
•Protected fields proliferate — More and more state is shared across the hierarchy through protected fields.
•Methods have if/else on type — Code checks instanceof to handle different subclass types, indicating the polymorphism isn't working.
•Super calls grow complex — Overriding methods have complex logic around when and how to call super.
•Common changes touch many files — A simple change requires modifications across multiple levels of the hierarchy.
•Tests specify hierarchy structure — Tests assert that class A extends B, rather than behavior.
•New developers struggle with hierarchy — Onboarding requires extensive study of the class structure.
•'It would be easier to rewrite' — Developers suggest starting over rather than modifying the existing hierarchy.

Quantifying Rigidity

Some metrics can help identify problematic hierarchies:

Metric	Concerning Value	What It Indicates
Depth of Inheritance	> 3 levels	Middle layers are likely trapped
Number of Subclasses	> 5 per parent	Parent changes affect too many classes
Protected Members	> 3 per class	Excessive shared state
Override Ratio	> 50% of methods overridden	Subclasses don't truly specialize
Super Call Complexity	> 2 super calls in one method	Complex parent dependency
Cross-Package Inheritance	Any	Coupling across module boundaries

Prevention Is Easier Than Cure

Summary: The Rigidity Reality

Inheritance hierarchies become rigid because of fundamental properties of the inheritance mechanism—not because of poor implementation. Let's consolidate the key lessons:

Key Takeaways

•IS-A relationships are permanent — Once declared, inheritance cannot be undone without major restructuring.
•Depth multiplies rigidity — Each level in a hierarchy adds constraints on all other levels.
•Width imposes lowest common denominator — Many subclasses force parents toward minimal or inappropriate abstractions.
•Requirements evolution conflicts with structural stability — The domain changes; the hierarchy resists change.
•Refactoring becomes exponentially harder — Standard refactoring techniques carry more risk and complexity in hierarchies.
•Cross-boundary inheritance is especially dangerous — Inheritance across packages, modules, or teams creates coordination overhead that defeats modularity.
•Recognize warning signs early — Identifying rigidity before it's severe allows for course correction.

What's Next

Page Complete

3 / 4