Shallow vs Deep Hierarchies - Designing Sound Inheritance Hierarchies | OneNoughtOne

0/290

System Design (HLD)Inheritance Hierarchies — Design Considerations

Designing Sound Inheritance Hierarchies

LevelIntermediate

Duration55 mins

TopicInheritance Hierarchies — Design Considerations

1 / 4

Shallow vs Deep Hierarchies

The Architecture of Class Relationships

When you introduce inheritance into a system, you're not just creating a parent-child relationship between two classes—you're establishing the foundation of a hierarchy. Like an organizational chart or a family tree, this hierarchy can grow in different directions: it can spread wide with many sibling classes at the same level, or it can grow tall with many generations of parent-child relationships stacked on top of each other.

The depth of your inheritance hierarchy—how many levels of inheritance exist from the root to the most derived class—profoundly impacts your system's understandability, maintainability, and flexibility. Get this wrong, and you'll find yourself trapped in a maze of tangled dependencies that resists every change.

What You Will Learn

By the end of this page, you will understand the fundamental tradeoffs between shallow and deep class hierarchies, recognize when each is appropriate, and develop intuition for structuring inheritance relationships that remain manageable as systems evolve.

Understanding Hierarchy Depth

Hierarchy depth refers to the number of inheritance levels from the base class (root) to the most derived class (leaf). Consider this progression:

Level 0: Object
         ↓
Level 1: Animal
         ↓
Level 2: Mammal
         ↓
Level 3: Carnivore
         ↓
Level 4: Feline
         ↓
Level 5: DomesticCat

This hierarchy has a depth of 5 (not counting Object, which is implicit in most languages). Every time you instantiate a DomesticCat, you're carrying the weight of five superclass definitions.

But depth alone doesn't tell the full story. Hierarchy breadth matters too—how many classes exist at each level, and how many different branches the hierarchy splits into.

Hierarchy Metrics and Their Implications
Metric	Definition	Implication
Depth of Inheritance Tree (DIT)	Levels from root to deepest leaf	Higher DIT = more inherited behavior, more complexity
Number of Children (NOC)	Direct subclasses of a class	Higher NOC = more reuse, but potential abstraction issues
Weighted Methods per Class (WMC)	Sum of method complexities in a class	Combined with DIT, indicates cognitive load
Coupling Between Objects (CBO)	Number of classes a class depends on	Deep hierarchies often increase CBO through inheritance

The Chidamber and Kemerer Metrics

These metrics come from the Chidamber and Kemerer (CK) metrics suite, published in 1994. Research has consistently shown that higher DIT values correlate with increased defect rates and maintenance difficulty. Most empirical studies suggest keeping DIT below 5 for optimal maintainability.

The Case for Shallow Hierarchies

Shallow hierarchies typically have 2-3 levels of inheritance. They favor composition over deep inheritance chains, keeping class relationships simple and explicit.

Consider a payment processing system with a shallow design:

shallow_payment_hierarchy.py
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
# Shallow Hierarchy (Depth = 1)
from abc import ABC, abstractmethod
 
class PaymentProcessor(ABC):
    """Base abstraction - defines the contract"""
    
    @abstractmethod
    def process(self, amount: float) -> bool:
        pass
    
    @abstractmethod
    def refund(self, transaction_id: str) -> bool:
        pass
 
class CreditCardProcessor(PaymentProcessor):
    """Direct implementation - no intermediate classes"""
    
    def __init__(self, api_client):
        self.api_client = api_client
    
    def process(self, amount: float) -> bool:
        return self.api_client.charge(amount)
    
    def refund(self, transaction_id: str) -> bool:
        return self.api_client.refund(transaction_id)
 
class PayPalProcessor(PaymentProcessor):
    """Another direct implementation"""
    
    def __init__(self, paypal_sdk):
        self.sdk = paypal_sdk
    
    def process(self, amount: float) -> bool:
        return self.sdk.create_payment(amount)
    
    def refund(self, transaction_id: str) -> bool:
        return self.sdk.refund_payment(transaction_id)
 
class CryptoProcessor(PaymentProcessor):
    """Yet another direct implementation"""
    
    def __init__(self, wallet_service):
        self.wallet = wallet_service
    
    def process(self, amount: float) -> bool:
        return self.wallet.transfer(amount)
    
    def refund(self, transaction_id: str) -> bool:
        return self.wallet.reverse_transfer(transaction_id)

Advantages of Shallow Hierarchies

•Immediate Understandability — You can understand any class by looking at it and its single parent. No need to trace through multiple levels to understand behavior.
•Flat Cognitive Load — Each class carries only its own complexity plus one parent. Developers can hold the entire relationship in working memory.
•Easy Onboarding — New team members grasp the structure quickly. The learning curve stays flat regardless of project size.
•Simpler Testing — Fewer inherited behaviors means fewer implicit dependencies to mock or stub. Unit tests are more isolated.
•Flexible Refactoring — Changes to any class have limited blast radius. You can modify implementations without worrying about ripple effects through many descendants.
•Clear Contracts — The relationship between abstraction and implementation is explicit. Each concrete class fully implements the contract.

The 'Rule of Three Levels'

Many experienced architects follow a mental guideline: if your hierarchy exceeds three levels (base → intermediate → concrete), question whether you actually need inheritance at all. Often, the intermediate levels can be replaced with composition.

The Case for Deeper Hierarchies

While shallow is often better, deeper hierarchies have legitimate uses—particularly when modeling domains with genuine taxonomic relationships or when building frameworks that need extension points at multiple levels.

Consider a game engine's entity system that genuinely benefits from depth:

game_entity_hierarchy.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
# Deeper Hierarchy (Depth = 4) - Justified by domain model
from abc import ABC, abstractmethod
 
class Entity(ABC):
    """Level 0: All game entities share these fundamentals"""
    
    def __init__(self, x: float, y: float):
        self.x = x
        self.y = y
        self.active = True
    
    @abstractmethod
    def update(self, delta_time: float):
        pass
 
class Actor(Entity):
    """Level 1: Entities that can act in the world"""
    
    def __init__(self, x: float, y: float, speed: float):
        super().__init__(x, y)
        self.speed = speed
        self.velocity_x = 0
        self.velocity_y = 0
    
    def move(self, delta_time: float):
        self.x += self.velocity_x * delta_time
        self.y += self.velocity_y * delta_time
 
class Character(Actor):
    """Level 2: Actors with health and combat capability"""
    
    def __init__(self, x: float, y: float, speed: float, health: int):
        super().__init__(x, y, speed)
        self.max_health = health
        self.current_health = health
    
    def take_damage(self, amount: int):
        self.current_health = max(0, self.current_health - amount)
        if self.current_health == 0:
            self.active = False
    
    def heal(self, amount: int):
        self.current_health = min(self.max_health, self.current_health + amount)
 
class Player(Character):
    """Level 3: Player-controlled character with inventory and experience"""
    
    def __init__(self, x: float, y: float):
        super().__init__(x, y, speed=100.0, health=100)
        self.inventory = []
        self.experience = 0
        self.level = 1
    
    def update(self, delta_time: float):
        self.handle_input()
        self.move(delta_time)
        self.check_level_up()
    
    def handle_input(self):
        # Process player input to set velocity
        pass
    
    def check_level_up(self):
        if self.experience >= self.level * 100:
            self.level += 1
            self.max_health += 10
 
class Enemy(Character):
    """Level 3: AI-controlled opponent"""
    
    def __init__(self, x: float, y: float, health: int, aggro_range: float):
        super().__init__(x, y, speed=50.0, health=health)
        self.aggro_range = aggro_range
        self.target = None
    
    def update(self, delta_time: float):
        self.scan_for_targets()
        self.pursue_target()
        self.move(delta_time)
    
    def scan_for_targets(self):
        # Find nearest player within aggro range
        pass
    
    def pursue_target(self):
        # Set velocity toward target
        pass

When Deeper Hierarchies Make Sense

•Genuine Taxonomic Domains — Scientific classifications, organizational structures, or game entity systems where each level adds meaningful, reusable behavior.
•Framework Extension Points — When building a framework that others extend, intermediate classes provide hooks without forcing implementers to rewrite common code.
•Incremental Capability Addition — Each level adds a discrete, cohesive set of capabilities that builds upon all previous levels.
•Stable Domain Models — When the domain is well-understood and unlikely to change, deep hierarchies codify that understanding clearly.
•Performance-Critical Reuse — In languages where method dispatch has overhead, shared behavior in parent classes avoids delegation costs.

The Justification Test

Before adding a new level to your hierarchy, ask: 'Does this level add genuine, cohesive behavior used by ALL descendants?' If not, you're probably better off with composition or mixins.

The Problems with Deep Hierarchies

Despite their occasional utility, deep hierarchies carry significant risks. These problems compound as depth increases, making them exponentially worse in very deep structures.

The Yo-Yo Problem:

When reading code in a deep hierarchy, developers must constantly jump back and forth between levels to understand what's happening. A method call might:

Be defined in the current class
Be inherited from the parent
Be inherited from the grandparent
Be defined in the current class but call super() which calls the grandparent's version

This 'yo-yoing' through the hierarchy is exhausting and error-prone.

yoyo_problem_example.py
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
# The Yo-Yo Problem: Where does behavior come from?
class A:
    def process(self):
        self.step1()  # Defined here
        self.step2()  # Defined here
        self.step3()  # Defined here
 
class B(A):
    def step2(self):  # Override step2
        self.validate()  # Where is validate()?
        super().step2()
        self.log()  # Where is log()?
 
class C(B):
    def step3(self):  # Override step3
        super().step3()
        self.finalize()  # Where is finalize()?
 
class D(C):
    def step1(self):  # Override step1
        self.initialize()  # Defined in E!
        super().step1()
 
class E(D):
    def initialize(self):
        pass
    
    def validate(self):
        pass
    
    def log(self):
        pass
    
    def finalize(self):
        pass
 
# When you call e.process(), what happens?
# You need to trace through ALL FIVE classes to understand
e = E()
e.process()  # Good luck understanding this!

Core Problems with Deep Hierarchies

•Cognitive Overload — Developers must hold multiple class definitions in memory simultaneously. Working memory has limits; deep hierarchies exceed them.
•Fragile Base Class Problem — Changes to any parent class can break descendants in unexpected ways. The more levels, the more potential break points.
•Hidden Dependencies — Subclasses depend on implementation details of all ancestors, not just their declared contracts. These dependencies are invisible until they break.
•Testing Complexity — Each level adds implicit setup and teardown. Testing a leaf class means testing all ancestor behavior, often inadvertently.
•Refactoring Paralysis — Fear of breaking descendant classes leads to 'just add another subclass' decisions, deepening the hierarchy further.
•Skill Barrier — New team members take much longer to become productive. They must internalize the entire hierarchy before making changes.

The Code Archaeology Problem

In deep hierarchies, understanding a bug often requires 'code archaeology'—digging through layers of history to find where behavior originated. A single method call might traverse 5+ classes before you find where it's actually defined. This dramatically increases debugging time.

Measuring Hierarchy Health

How do you know if your hierarchy is too deep? Beyond subjective feelings of complexity, you can apply objective metrics and heuristics.

Hierarchy Health Indicators
Indicator	Healthy Range	Warning Signs
Maximum Depth	1-3 levels	Any class with DIT > 5
Average Depth	< 2	Average DIT > 3 across codebase
Classes per Level	Decreasing	More classes at deeper levels
Override Count	Minimal	Many methods overridden at each level
Super() Chains	0-1 calls	super() chains through 3+ levels
Abstract Methods at Leaf	None	Leaf classes still have abstract methods

The 'Override Ratio' Smell:

If a subclass overrides more than 30% of its parent's methods, something is wrong. Either:

The parent is doing too much (violates SRP)
The subclass isn't really an 'IS-A' relationship
You should use composition instead of inheritance

The 'Empty Intermediate Class' Smell:

If you have classes whose sole purpose is to sit in the hierarchy without adding behavior, you've over-engineered the structure:

empty_intermediate_class.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# BAD: Empty intermediate classes add depth without value
class Vehicle(ABC):
    @abstractmethod
    def move(self): pass
 
class LandVehicle(Vehicle):
    pass  # Adds nothing!
 
class FourWheeledLandVehicle(LandVehicle):
    pass  # Still adds nothing!
 
class Car(FourWheeledLandVehicle):
    def move(self):
        self.drive()  # Finally, actual behavior
 
# BETTER: Remove unnecessary levels
class Vehicle(ABC):
    @abstractmethod
    def move(self): pass
 
class Car(Vehicle):
    def move(self):
        self.drive()

The 'Could I Explain This?' Test

A practical heuristic: Can you explain the class hierarchy to a new team member in under 5 minutes? If not, it's too complex. This 'explainability test' catches problems that metrics might miss.

Flattening Deep Hierarchies

When you inherit a deep hierarchy or realize yours has grown unwieldy, you need strategies to flatten it. This is delicate refactoring work—you must preserve behavior while simplifying structure.

Strategy 1: Replace Intermediate Classes with Composition

Identify intermediate classes that exist solely to share behavior among subclasses. Extract that behavior into separate components and inject them:

before_flattening.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# BEFORE: Deep hierarchy
class Entity:
    def render(self): pass
 
class PhysicsEntity(Entity):
    def apply_physics(self): pass
 
class CollidableEntity(PhysicsEntity):
    def check_collision(self): pass
 
class AnimatedEntity(CollidableEntity):
    def animate(self): pass
 
class Player(AnimatedEntity):
    def handle_input(self): pass

after_flattening.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# AFTER: Shallow + Composition
class Entity:
    def __init__(self):
        self.physics = None
        self.collision = None
        self.animation = None
    
    def update(self):
        if self.physics:
            self.physics.update(self)
        if self.collision:
            self.collision.check(self)
        if self.animation:
            self.animation.animate(self)
 
class Player(Entity):
    def __init__(self):
        super().__init__()
        self.physics = PhysicsComponent()
        self.collision = CollisionComponent()
        self.animation = AnimationComponent()

Strategy 2: Collapse Levels Using Template Method

When intermediate classes differ only in specific behaviors, use the Template Method pattern to collapse them into a single class with extension points:

template_method_collapse.py
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
# BEFORE: Multiple levels for slight variations
class DataProcessor:
    def process(self, data):
        self.validate(data)
        self.transform(data)
        self.save(data)
 
class JSONProcessor(DataProcessor):
    def validate(self, data):
        # JSON validation
        pass
 
class XMLProcessor(DataProcessor):
    def validate(self, data):
        # XML validation
        pass
 
# AFTER: Single class with strategy injection
class DataProcessor:
    def __init__(self, validator, transformer, saver):
        self.validator = validator
        self.transformer = transformer
        self.saver = saver
    
    def process(self, data):
        self.validator(data)
        self.transformer(data)
        self.saver(data)
 
# Create processors with different behaviors
json_processor = DataProcessor(
    validator=validate_json,
    transformer=transform_json,
    saver=save_json
)

Incremental Flattening

Don't try to flatten an entire deep hierarchy at once. Work from the bottom up: collapse the deepest levels first, then work toward the root. This approach limits the blast radius of each change and lets you verify behavior preservation at each step.

Design Principles for Hierarchy Depth

After examining both extremes, we can distill key principles for managing inheritance hierarchy depth:

Core Design Principles

•Default to Shallow — Start with the shallowest possible hierarchy. Add depth only when you have concrete, demonstrated need—not anticipated future flexibility.
•Each Level Must Earn Its Place — Every level of inheritance must add genuine, cohesive behavior used by ALL descendants. Empty or partially-used levels are waste.
•Prefer Composition for Optional Behavior — If some subclasses need behavior that others don't, use composition rather than creating branching hierarchies.
•Three Levels is Usually Enough — Abstract base → intermediate category → concrete implementation handles most legitimate needs. Question hierarchies deeper than this.
•Measure and Monitor — Track DIT metrics over time. Increasing depth is a trend that should trigger design review.
•The 'One Minute Rule' — Any developer should be able to understand what a class does (including inherited behavior) within one minute of opening it.

Choosing Hierarchy Depth by Scenario
Scenario	Recommended Approach	Reason
Application code	Shallow (1-2 levels)	Simplicity and maintainability are paramount
Framework/library development	Moderate (2-3 levels)	Need extension points for users
Domain with natural taxonomy	Match the domain (2-4 levels)	Model the genuine structure
Rapidly changing domain	Shallow + composition	Deep hierarchies resist change
Performance-critical code	Case-by-case	Balance performance vs maintainability

Page Complete

You now understand the critical tradeoffs between shallow and deep inheritance hierarchies. Shallow hierarchies favor simplicity and maintainability; deep hierarchies can model complex domains but carry significant cognitive and maintenance costs. The next page explores another dimension of hierarchy design: single versus multiple inheritance.