Inheritance Hierarchies Design - Learning Module

Loading content...

0/246

Designing Inheritance Hierarchies

Putting It All Together

We've explored the dimensions of inheritance hierarchy design—depth considerations, single versus multiple inheritance, and the treacherous diamond problem. Now it's time to synthesize these insights into a practical framework for designing inheritance structures that stand the test of time.

Good inheritance design isn't about following rigid rules—it's about understanding tradeoffs and making informed choices. This page provides you with the mental models, decision frameworks, and concrete checklists you need to design hierarchies that enhance rather than hinder your codebase.

What You Will Learn

By the end of this page, you will have a complete toolkit for inheritance hierarchy design: when to use inheritance, how to structure hierarchies, what patterns to prefer, and how to validate your design decisions. You'll leave with actionable checklists you can apply immediately.

First Question: Should You Use Inheritance?

Before designing an inheritance hierarchy, ask whether you need one at all. Inheritance is a powerful tool, but it's not always the right choice.

The Four Prerequisites for Inheritance:

Inheritance is appropriate when ALL of the following conditions are met:

Prerequisites for Using Inheritance

•True IS-A Relationship — The subclass IS genuinely a specialized version of the parent. A Circle IS-A Shape, but a Circle IS-NOT-A Wheel (despite having a circular shape).
•Behavioral Substitutability — Every place the parent is used, the child can substitute without breaking functionality (Liskov Substitution Principle). A Penguin violates this if Bird promises fly() that works.
•Stable Abstraction — The parent class represents a stable, well-understood concept unlikely to change frequently. Inheritance to unstable abstractions creates cascading change.
•Genuine Reuse — There's significant code you'll reuse from the parent, not just a few lines. If you're overriding most methods, inheritance buys you nothing.

When to Choose Alternatives:

Inheritance vs Alternatives Decision Matrix
Situation	Better Choice	Why
Need to share code but no IS-A	Composition	HAS-A is clearer, more flexible
Multiple cross-cutting capabilities	Interfaces + Composition	Avoids diamond, allows mixing
Behavior varies at runtime	Strategy Pattern	Inheritance is static, strategy is dynamic
Want to extend sealed/final class	Wrapper/Decorator	Composition works where inheritance can't
Parent has many unneeded features	Interface + Delegation	Only expose what you need
Relationship might change	Composition	Easier to refactor than inheritance

The 'Future Change' Heuristic

Ask yourself: 'In 2 years, is someone likely to add a new type that doesn't cleanly fit this hierarchy?' If yes, prefer composition and interfaces over rigid inheritance trees.

Structuring the Hierarchy

Once you've decided inheritance is appropriate, structure your hierarchy thoughtfully. Follow these architectural principles:

Principle 1: Abstract at the Top, Concrete at the Leaves

The root of your hierarchy should be abstract (or an interface). Only leaf classes—those with no subclasses—should be concrete and instantiable.

hierarchy_structure.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
from abc import ABC, abstractmethod
 
# GOOD: Abstract root, concrete leaves
class Shape(ABC):  # Abstract - cannot instantiate
    @abstractmethod
    def area(self) -> float: pass
    
    @abstractmethod
    def perimeter(self) -> float: pass
 
class Polygon(Shape):  # Still abstract - missing implementations
    @abstractmethod
    def num_sides(self) -> int: pass
 
class Circle(Shape):  # Concrete leaf - fully implemented
    def __init__(self, radius: float):
        self.radius = radius
    
    def area(self) -> float:
        return 3.14159 * self.radius ** 2
    
    def perimeter(self) -> float:
        return 2 * 3.14159 * self.radius
 
class Rectangle(Polygon):  # Concrete leaf
    def __init__(self, width: float, height: float):
        self.width = width
        self.height = height
    
    def area(self) -> float:
        return self.width * self.height
    
    def perimeter(self) -> float:
        return 2 * (self.width + self.height)
    
    def num_sides(self) -> int:
        return 4
 
# Usage: Only work with the abstract type
def print_shape_info(shape: Shape):
    print(f"Area: {shape.area()}, Perimeter: {shape.perimeter()}")

Principle 2: Maintain Consistent Abstraction Levels

Each level in your hierarchy should represent the same 'level' of abstraction. Don't mix apples and oranges:

inconsistent_levels.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# BAD: Mixed abstraction levels
class Vehicle:
    pass
 
# These are at different 
# abstraction levels:
class Car(Vehicle):       # Type
    pass
class BlueCar(Vehicle):   # Color!
    pass
class FastVehicle(Vehicle): # Attribute!
    pass
class ToyotaCamry(Vehicle):  # Instance!
    pass

consistent_levels.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# GOOD: Consistent abstraction
class Vehicle:
    pass
 
# All at same level: vehicle types
class Car(Vehicle):
    pass
class Truck(Vehicle):
    pass
class Motorcycle(Vehicle):
    pass
 
# Color, speed, brand are 
# ATTRIBUTES, not subclasses

Principle 3: Prefer Wide Over Deep

Given the choice between adding another level of depth or another sibling at the same level, prefer siblings. Wide hierarchies are easier to understand and modify.

The 'Family Tree' Mental Model

Think of your hierarchy like a family tree. The 'oldest ancestor' should be the most abstract. Each generation adds specialization. The 'youngest generation' (leaf classes) are the concrete instances you actually use. No generation should skip the abstraction pattern of its parent.

Designing Methods and State in Hierarchies

How you distribute methods and state across your hierarchy determines its quality. Follow these guidelines:

State Placement Rules:

Where to Place State

•Common State Goes Up — If ALL descendants need an attribute, define it in the parent. Every Shape has area, so area() belongs in Shape.
•Specific State Goes Down — If only SOME descendants need an attribute, don't force it on all. Only Rectangle has width, not all Shapes.
•Avoid Unused Inherited State — If a child inherits state it never uses, reconsider your hierarchy.
•Prefer Computed Over Stored — If a value can be computed from other state, prefer a method over a field. Less duplication, less inconsistency.

Method Placement Rules:

method_placement.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
from abc import ABC, abstractmethod
 
class Shape(ABC):
    # Abstract method: ALL children MUST implement
    @abstractmethod
    def area(self) -> float:
        """Every shape has area, but calculation differs."""
        pass
    
    # Template method: common structure, customizable steps
    def describe(self) -> str:
        """Common description format for all shapes."""
        return f"{self.__class__.__name__}: area={self.area():.2f}"
    
    # Concrete method: same implementation for all children
    def scale(self, factor: float) -> 'Shape':
        """Scaling logic is the same for all shapes."""
        # Implementation...
        pass
 
class Circle(Shape):
    def __init__(self, radius: float):
        self.radius = radius
    
    # Implement abstract method
    def area(self) -> float:
        return 3.14159 * self.radius ** 2
    
    # Optional: Override template method for customization
    def describe(self) -> str:
        base = super().describe()
        return f"{base}, radius={self.radius}"
    
    # Add child-specific methods
    def circumference(self) -> float:
        """Only circles have circumference."""
        return 2 * 3.14159 * self.radius

Method Types in Hierarchies
Method Type	Definition	When to Use
Abstract	No implementation; children must provide	Behavior varies completely between children
Template	Partial implementation calling abstract/overridable methods	Common structure, varying details
Concrete (final)	Full implementation children shouldn't override	Invariant behavior across all descendants
Default	Full implementation children CAN override	Sensible default, customizable if needed

Proven Hierarchy Patterns

Certain inheritance patterns recur across domains because they solve common problems well. Learn to recognize and apply them:

Pattern 1: The Template Method Hierarchy

An abstract parent defines the algorithm skeleton; concrete children fill in the specifics.

template_method_pattern.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
from abc import ABC, abstractmethod
 
class DataExporter(ABC):
    """Template Method Pattern: Fixed algorithm, customizable steps."""
    
    def export(self, data: list) -> str:
        """The template method - algorithm skeleton is fixed."""
        self.validate(data)           # Concrete step
        formatted = self.format(data)  # Abstract step - varies
        return self.write(formatted)   # Abstract step - varies
    
    def validate(self, data: list) -> None:
        """Concrete method: validation is the same for all."""
        if not data:
            raise ValueError("Cannot export empty data")
    
    @abstractmethod
    def format(self, data: list) -> str:
        """Abstract: each exporter formats differently."""
        pass
    
    @abstractmethod
    def write(self, content: str) -> str:
        """Abstract: each exporter writes differently."""
        pass
 
class CSVExporter(DataExporter):
    def format(self, data: list) -> str:
        return "
".join(",".join(str(cell) for cell in row) for row in data)
    
    def write(self, content: str) -> str:
        return f"data:text/csv,{content}"
 
class JSONExporter(DataExporter):
    def format(self, data: list) -> str:
        import json
        return json.dumps(data)
    
    def write(self, content: str) -> str:
        return f"data:application/json,{content}"

Pattern 2: The Strategy Hierarchy

A flat hierarchy of strategies implementing a common interface. Prefer this when algorithms are interchangeable at runtime.

strategy_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
from abc import ABC, abstractmethod
 
class PaymentStrategy(ABC):
    """Strategy Pattern: Interchangeable algorithms."""
    
    @abstractmethod
    def process(self, amount: float) -> bool: pass
    
    @abstractmethod
    def get_fee(self, amount: float) -> float: pass
 
class CreditCardPayment(PaymentStrategy):
    def process(self, amount: float) -> bool:
        return self.charge_card(amount)
    
    def get_fee(self, amount: float) -> float:
        return amount * 0.029  # 2.9% fee
    
    def charge_card(self, amount: float) -> bool:
        # Card-specific logic
        return True
 
class PayPalPayment(PaymentStrategy):
    def process(self, amount: float) -> bool:
        return self.paypal_transfer(amount)
    
    def get_fee(self, amount: float) -> float:
        return amount * 0.035 + 0.30  # 3.5% + $0.30
    
    def paypal_transfer(self, amount: float) -> bool:
        return True
 
# Usage: Select strategy at runtime
class Checkout:
    def __init__(self, strategy: PaymentStrategy):
        self.strategy = strategy
    
    def complete_purchase(self, amount: float) -> bool:
        fee = self.strategy.get_fee(amount)
        return self.strategy.process(amount + fee)

Pattern 3: The Composite Hierarchy

Leaf and composite nodes share a common interface, enabling tree structures.

composite_pattern.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
from abc import ABC, abstractmethod
from typing import List
 
class FileSystemEntry(ABC):
    """Composite Pattern: Uniform treatment of parts and wholes."""
    
    def __init__(self, name: str):
        self.name = name
    
    @abstractmethod
    def get_size(self) -> int: pass
    
    @abstractmethod
    def display(self, indent: int = 0) -> str: pass
 
class File(FileSystemEntry):
    """Leaf node: no children."""
    
    def __init__(self, name: str, size: int):
        super().__init__(name)
        self.size = size
    
    def get_size(self) -> int:
        return self.size
    
    def display(self, indent: int = 0) -> str:
        return " " * indent + f"📄 {self.name} ({self.size}B)"
 
class Directory(FileSystemEntry):
    """Composite node: contains children."""
    
    def __init__(self, name: str):
        super().__init__(name)
        self.children: List[FileSystemEntry] = []
    
    def add(self, entry: FileSystemEntry) -> None:
        self.children.append(entry)
    
    def get_size(self) -> int:
        return sum(child.get_size() for child in self.children)
    
    def display(self, indent: int = 0) -> str:
        lines = [" " * indent + f"📁 {self.name}/"]
        for child in self.children:
            lines.append(child.display(indent + 2))
        return "
".join(lines)

Hierarchy Anti-Patterns

Learning what NOT to do is as important as learning good patterns. These anti-patterns signal design problems:

Hierarchy Anti-Patterns

•The God Hierarchy — One massive base class with dozens of methods that every child must understand. Children override random subsets. Symptom: You can't understand a child without reading the entire parent.
•The Refused Bequest — Children inherit methods they don't want and must disable or override with empty implementations. Symptom: raise NotImplementedError() or pass in overrides.
•The YoYo Hierarchy — Understanding any method requires bouncing between many levels. Symptom: Debugger sessions that traverse 5+ stack frames within the same hierarchy.
•The Swiss Army Knife — An interface with so many methods that implementations provide partial, inconsistent coverage. Symptom: Many implementations throw UnsupportedOperationException.
•The Speculative Hierarchy — Levels added for 'future flexibility' that never materialize. Symptom: Abstract classes with only one concrete child, or empty intermediate classes.
•The Attribute Hierarchy — Subclasses created for what should be attribute differences. Symptom: RedCircle, BlueCircle, GreenCircle instead of Circle(color='red').

refused_bequest_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
# ANTI-PATTERN: Refused Bequest
class Bird:
    def fly(self):
        print("Flying high!")
    
    def eat(self):
        print("Eating")
 
class Penguin(Bird):
    def fly(self):
        # Penguin CAN'T fly, but inherits the method
        raise NotImplementedError("Penguins cannot fly!")
    
    # Has to inherit fly() even though it's meaningless
 
# BETTER: Separate flying from being a bird
class Bird:
    def eat(self):
        print("Eating")
 
class FlyingBird(Bird):
    def fly(self):
        print("Flying high!")
 
class Penguin(Bird):
    def swim(self):
        print("Swimming!")
    # No fly() method at all - honest interface

The Refactoring Signal

If you find yourself writing 'Override just to disable' or 'Empty implementation required by interface', your hierarchy is fighting you. This is a strong signal to reconsider your abstractions.

The Inheritance Hierarchy Design Checklist

Use this checklist when designing or reviewing inheritance hierarchies. Each question should have a confident 'yes' answer:

Before Creating a Hierarchy

•Is there a genuine IS-A relationship between parent and children?
•Would composition be simpler and equally effective?
•Is the parent abstraction stable and well-understood?
•Will children reuse significant code from the parent?
•Can children substitute for the parent everywhere (LSP)?

When Structuring the Hierarchy

•Is the root abstract or an interface?
•Are only leaf classes concrete?
•Is every level at a consistent abstraction?
•Are there fewer than 4 inheritance levels?
•Does every level add genuine, cohesive behavior?

When Placing Methods and State

•Is shared state defined only in the highest common location?
•Does no child inherit state it doesn't use?
•Are abstract methods genuinely variable between children?
•Are template methods genuinely sharing algorithm structure?
•Do children override less than 30% of parent methods?

When Reviewing for Quality

•Can a new team member understand the hierarchy in 5 minutes?
•Is there no 'refused bequest' pattern (disabled inherited methods)?
•Are there no empty intermediate classes?
•Can you understand any class without reading all ancestors?
•Has this structure been stable for multiple releases?

Module Summary: Designing Sound Inheritance Hierarchies

This module has taken you through the critical decisions in inheritance hierarchy design. Let's consolidate the key insights:

Module Concepts Summary
Concept	Key Insight	Practical Guideline
Hierarchy Depth	Deeper = harder to understand and maintain	Keep depth ≤ 3; measure DIT; flatten when possible
Single vs Multiple	Single is simpler; multiple models cross-cutting domains	Default to single; use interfaces for multiplicity
Diamond Problem	Shared ancestors create ambiguity in state and behavior	Avoid diamonds; use virtual inheritance or MRO if needed
Structure	Abstract at top, concrete at leaves	Maintain consistent abstraction levels per depth
Method Placement	Common behavior up, specific behavior down	Use template methods for shared structure, abstract for variation
Anti-Patterns	Refused bequest, speculative generality, god hierarchies	If fighting the hierarchy, reconsider the abstraction

The Principal Engineer's Mindset

•Question inheritance instinctively. Before reaching for extends, ask if has-a would be clearer than is-a.
•Favor shallow, wide hierarchies. Cognitive load matters more than theoretical elegance.
•Design for the reader. The hierarchy should tell a clear story to someone new to the codebase.
•Track metrics over time. Rising DIT or NOC often predicts maintenance problems before they strike.
•Refactor proactively. When you see an anti-pattern forming, address it before it ossifies into legacy.

Module Complete

You've mastered the art of inheritance hierarchy design. You understand depth tradeoffs, inheritance multiplicity, the diamond problem, and practical design principles. Apply these insights to create hierarchies that enhance code clarity and maintainability rather than hindering them.

Designing Inheritance Hierarchies

Putting It All Together

What You Will Learn

First Question: Should You Use Inheritance?

Before designing an inheritance hierarchy, ask whether you need one at all. Inheritance is a powerful tool, but it's not always the right choice.

The Four Prerequisites for Inheritance:

Inheritance is appropriate when ALL of the following conditions are met:

Prerequisites for Using Inheritance

•True IS-A Relationship — The subclass IS genuinely a specialized version of the parent. A Circle IS-A Shape, but a Circle IS-NOT-A Wheel (despite having a circular shape).
•Behavioral Substitutability — Every place the parent is used, the child can substitute without breaking functionality (Liskov Substitution Principle). A Penguin violates this if Bird promises fly() that works.
•Stable Abstraction — The parent class represents a stable, well-understood concept unlikely to change frequently. Inheritance to unstable abstractions creates cascading change.
•Genuine Reuse — There's significant code you'll reuse from the parent, not just a few lines. If you're overriding most methods, inheritance buys you nothing.

When to Choose Alternatives:

Inheritance vs Alternatives Decision Matrix
Situation	Better Choice	Why
Need to share code but no IS-A	Composition	HAS-A is clearer, more flexible
Multiple cross-cutting capabilities	Interfaces + Composition	Avoids diamond, allows mixing
Behavior varies at runtime	Strategy Pattern	Inheritance is static, strategy is dynamic
Want to extend sealed/final class	Wrapper/Decorator	Composition works where inheritance can't
Parent has many unneeded features	Interface + Delegation	Only expose what you need
Relationship might change	Composition	Easier to refactor than inheritance

The 'Future Change' Heuristic

Ask yourself: 'In 2 years, is someone likely to add a new type that doesn't cleanly fit this hierarchy?' If yes, prefer composition and interfaces over rigid inheritance trees.

Structuring the Hierarchy

Once you've decided inheritance is appropriate, structure your hierarchy thoughtfully. Follow these architectural principles:

Principle 1: Abstract at the Top, Concrete at the Leaves

The root of your hierarchy should be abstract (or an interface). Only leaf classes—those with no subclasses—should be concrete and instantiable.

hierarchy_structure.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
from abc import ABC, abstractmethod
 
# GOOD: Abstract root, concrete leaves
class Shape(ABC):  # Abstract - cannot instantiate
    @abstractmethod
    def area(self) -> float: pass
    
    @abstractmethod
    def perimeter(self) -> float: pass
 
class Polygon(Shape):  # Still abstract - missing implementations
    @abstractmethod
    def num_sides(self) -> int: pass
 
class Circle(Shape):  # Concrete leaf - fully implemented
    def __init__(self, radius: float):
        self.radius = radius
    
    def area(self) -> float:
        return 3.14159 * self.radius ** 2
    
    def perimeter(self) -> float:
        return 2 * 3.14159 * self.radius
 
class Rectangle(Polygon):  # Concrete leaf
    def __init__(self, width: float, height: float):
        self.width = width
        self.height = height
    
    def area(self) -> float:
        return self.width * self.height
    
    def perimeter(self) -> float:
        return 2 * (self.width + self.height)
    
    def num_sides(self) -> int:
        return 4
 
# Usage: Only work with the abstract type
def print_shape_info(shape: Shape):
    print(f"Area: {shape.area()}, Perimeter: {shape.perimeter()}")

Principle 2: Maintain Consistent Abstraction Levels

Each level in your hierarchy should represent the same 'level' of abstraction. Don't mix apples and oranges:

inconsistent_levels.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# BAD: Mixed abstraction levels
class Vehicle:
    pass
 
# These are at different 
# abstraction levels:
class Car(Vehicle):       # Type
    pass
class BlueCar(Vehicle):   # Color!
    pass
class FastVehicle(Vehicle): # Attribute!
    pass
class ToyotaCamry(Vehicle):  # Instance!
    pass

consistent_levels.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# GOOD: Consistent abstraction
class Vehicle:
    pass
 
# All at same level: vehicle types
class Car(Vehicle):
    pass
class Truck(Vehicle):
    pass
class Motorcycle(Vehicle):
    pass
 
# Color, speed, brand are 
# ATTRIBUTES, not subclasses

Principle 3: Prefer Wide Over Deep

Given the choice between adding another level of depth or another sibling at the same level, prefer siblings. Wide hierarchies are easier to understand and modify.

The 'Family Tree' Mental Model

Designing Methods and State in Hierarchies

How you distribute methods and state across your hierarchy determines its quality. Follow these guidelines:

State Placement Rules:

Where to Place State

•Common State Goes Up — If ALL descendants need an attribute, define it in the parent. Every Shape has area, so area() belongs in Shape.
•Specific State Goes Down — If only SOME descendants need an attribute, don't force it on all. Only Rectangle has width, not all Shapes.
•Avoid Unused Inherited State — If a child inherits state it never uses, reconsider your hierarchy.
•Prefer Computed Over Stored — If a value can be computed from other state, prefer a method over a field. Less duplication, less inconsistency.

Method Placement Rules:

method_placement.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
from abc import ABC, abstractmethod
 
class Shape(ABC):
    # Abstract method: ALL children MUST implement
    @abstractmethod
    def area(self) -> float:
        """Every shape has area, but calculation differs."""
        pass
    
    # Template method: common structure, customizable steps
    def describe(self) -> str:
        """Common description format for all shapes."""
        return f"{self.__class__.__name__}: area={self.area():.2f}"
    
    # Concrete method: same implementation for all children
    def scale(self, factor: float) -> 'Shape':
        """Scaling logic is the same for all shapes."""
        # Implementation...
        pass
 
class Circle(Shape):
    def __init__(self, radius: float):
        self.radius = radius
    
    # Implement abstract method
    def area(self) -> float:
        return 3.14159 * self.radius ** 2
    
    # Optional: Override template method for customization
    def describe(self) -> str:
        base = super().describe()
        return f"{base}, radius={self.radius}"
    
    # Add child-specific methods
    def circumference(self) -> float:
        """Only circles have circumference."""
        return 2 * 3.14159 * self.radius

Method Types in Hierarchies
Method Type	Definition	When to Use
Abstract	No implementation; children must provide	Behavior varies completely between children
Template	Partial implementation calling abstract/overridable methods	Common structure, varying details
Concrete (final)	Full implementation children shouldn't override	Invariant behavior across all descendants
Default	Full implementation children CAN override	Sensible default, customizable if needed

Proven Hierarchy Patterns

Certain inheritance patterns recur across domains because they solve common problems well. Learn to recognize and apply them:

Pattern 1: The Template Method Hierarchy

An abstract parent defines the algorithm skeleton; concrete children fill in the specifics.

template_method_pattern.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
from abc import ABC, abstractmethod
 
class DataExporter(ABC):
    """Template Method Pattern: Fixed algorithm, customizable steps."""
    
    def export(self, data: list) -> str:
        """The template method - algorithm skeleton is fixed."""
        self.validate(data)           # Concrete step
        formatted = self.format(data)  # Abstract step - varies
        return self.write(formatted)   # Abstract step - varies
    
    def validate(self, data: list) -> None:
        """Concrete method: validation is the same for all."""
        if not data:
            raise ValueError("Cannot export empty data")
    
    @abstractmethod
    def format(self, data: list) -> str:
        """Abstract: each exporter formats differently."""
        pass
    
    @abstractmethod
    def write(self, content: str) -> str:
        """Abstract: each exporter writes differently."""
        pass
 
class CSVExporter(DataExporter):
    def format(self, data: list) -> str:
        return "
".join(",".join(str(cell) for cell in row) for row in data)
    
    def write(self, content: str) -> str:
        return f"data:text/csv,{content}"
 
class JSONExporter(DataExporter):
    def format(self, data: list) -> str:
        import json
        return json.dumps(data)
    
    def write(self, content: str) -> str:
        return f"data:application/json,{content}"

Pattern 2: The Strategy Hierarchy

A flat hierarchy of strategies implementing a common interface. Prefer this when algorithms are interchangeable at runtime.

strategy_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
from abc import ABC, abstractmethod
 
class PaymentStrategy(ABC):
    """Strategy Pattern: Interchangeable algorithms."""
    
    @abstractmethod
    def process(self, amount: float) -> bool: pass
    
    @abstractmethod
    def get_fee(self, amount: float) -> float: pass
 
class CreditCardPayment(PaymentStrategy):
    def process(self, amount: float) -> bool:
        return self.charge_card(amount)
    
    def get_fee(self, amount: float) -> float:
        return amount * 0.029  # 2.9% fee
    
    def charge_card(self, amount: float) -> bool:
        # Card-specific logic
        return True
 
class PayPalPayment(PaymentStrategy):
    def process(self, amount: float) -> bool:
        return self.paypal_transfer(amount)
    
    def get_fee(self, amount: float) -> float:
        return amount * 0.035 + 0.30  # 3.5% + $0.30
    
    def paypal_transfer(self, amount: float) -> bool:
        return True
 
# Usage: Select strategy at runtime
class Checkout:
    def __init__(self, strategy: PaymentStrategy):
        self.strategy = strategy
    
    def complete_purchase(self, amount: float) -> bool:
        fee = self.strategy.get_fee(amount)
        return self.strategy.process(amount + fee)

Pattern 3: The Composite Hierarchy

Leaf and composite nodes share a common interface, enabling tree structures.

composite_pattern.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
from abc import ABC, abstractmethod
from typing import List
 
class FileSystemEntry(ABC):
    """Composite Pattern: Uniform treatment of parts and wholes."""
    
    def __init__(self, name: str):
        self.name = name
    
    @abstractmethod
    def get_size(self) -> int: pass
    
    @abstractmethod
    def display(self, indent: int = 0) -> str: pass
 
class File(FileSystemEntry):
    """Leaf node: no children."""
    
    def __init__(self, name: str, size: int):
        super().__init__(name)
        self.size = size
    
    def get_size(self) -> int:
        return self.size
    
    def display(self, indent: int = 0) -> str:
        return " " * indent + f"📄 {self.name} ({self.size}B)"
 
class Directory(FileSystemEntry):
    """Composite node: contains children."""
    
    def __init__(self, name: str):
        super().__init__(name)
        self.children: List[FileSystemEntry] = []
    
    def add(self, entry: FileSystemEntry) -> None:
        self.children.append(entry)
    
    def get_size(self) -> int:
        return sum(child.get_size() for child in self.children)
    
    def display(self, indent: int = 0) -> str:
        lines = [" " * indent + f"📁 {self.name}/"]
        for child in self.children:
            lines.append(child.display(indent + 2))
        return "
".join(lines)

Hierarchy Anti-Patterns

Learning what NOT to do is as important as learning good patterns. These anti-patterns signal design problems:

Hierarchy Anti-Patterns

•The God Hierarchy — One massive base class with dozens of methods that every child must understand. Children override random subsets. Symptom: You can't understand a child without reading the entire parent.
•The Refused Bequest — Children inherit methods they don't want and must disable or override with empty implementations. Symptom: raise NotImplementedError() or pass in overrides.
•The YoYo Hierarchy — Understanding any method requires bouncing between many levels. Symptom: Debugger sessions that traverse 5+ stack frames within the same hierarchy.
•The Swiss Army Knife — An interface with so many methods that implementations provide partial, inconsistent coverage. Symptom: Many implementations throw UnsupportedOperationException.
•The Speculative Hierarchy — Levels added for 'future flexibility' that never materialize. Symptom: Abstract classes with only one concrete child, or empty intermediate classes.
•The Attribute Hierarchy — Subclasses created for what should be attribute differences. Symptom: RedCircle, BlueCircle, GreenCircle instead of Circle(color='red').

refused_bequest_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
# ANTI-PATTERN: Refused Bequest
class Bird:
    def fly(self):
        print("Flying high!")
    
    def eat(self):
        print("Eating")
 
class Penguin(Bird):
    def fly(self):
        # Penguin CAN'T fly, but inherits the method
        raise NotImplementedError("Penguins cannot fly!")
    
    # Has to inherit fly() even though it's meaningless
 
# BETTER: Separate flying from being a bird
class Bird:
    def eat(self):
        print("Eating")
 
class FlyingBird(Bird):
    def fly(self):
        print("Flying high!")
 
class Penguin(Bird):
    def swim(self):
        print("Swimming!")
    # No fly() method at all - honest interface

The Refactoring Signal

If you find yourself writing 'Override just to disable' or 'Empty implementation required by interface', your hierarchy is fighting you. This is a strong signal to reconsider your abstractions.

The Inheritance Hierarchy Design Checklist

Use this checklist when designing or reviewing inheritance hierarchies. Each question should have a confident 'yes' answer:

Before Creating a Hierarchy

•Is there a genuine IS-A relationship between parent and children?
•Would composition be simpler and equally effective?
•Is the parent abstraction stable and well-understood?
•Will children reuse significant code from the parent?
•Can children substitute for the parent everywhere (LSP)?

When Structuring the Hierarchy

•Is the root abstract or an interface?
•Are only leaf classes concrete?
•Is every level at a consistent abstraction?
•Are there fewer than 4 inheritance levels?
•Does every level add genuine, cohesive behavior?

When Placing Methods and State

•Is shared state defined only in the highest common location?
•Does no child inherit state it doesn't use?
•Are abstract methods genuinely variable between children?
•Are template methods genuinely sharing algorithm structure?
•Do children override less than 30% of parent methods?

When Reviewing for Quality

•Can a new team member understand the hierarchy in 5 minutes?
•Is there no 'refused bequest' pattern (disabled inherited methods)?
•Are there no empty intermediate classes?
•Can you understand any class without reading all ancestors?
•Has this structure been stable for multiple releases?

Module Summary: Designing Sound Inheritance Hierarchies

This module has taken you through the critical decisions in inheritance hierarchy design. Let's consolidate the key insights:

Module Concepts Summary
Concept	Key Insight	Practical Guideline
Hierarchy Depth	Deeper = harder to understand and maintain	Keep depth ≤ 3; measure DIT; flatten when possible
Single vs Multiple	Single is simpler; multiple models cross-cutting domains	Default to single; use interfaces for multiplicity
Diamond Problem	Shared ancestors create ambiguity in state and behavior	Avoid diamonds; use virtual inheritance or MRO if needed
Structure	Abstract at top, concrete at leaves	Maintain consistent abstraction levels per depth
Method Placement	Common behavior up, specific behavior down	Use template methods for shared structure, abstract for variation
Anti-Patterns	Refused bequest, speculative generality, god hierarchies	If fighting the hierarchy, reconsider the abstraction

The Principal Engineer's Mindset

•Question inheritance instinctively. Before reaching for extends, ask if has-a would be clearer than is-a.
•Favor shallow, wide hierarchies. Cognitive load matters more than theoretical elegance.
•Design for the reader. The hierarchy should tell a clear story to someone new to the codebase.
•Track metrics over time. Rising DIT or NOC often predicts maintenance problems before they strike.
•Refactor proactively. When you see an anti-pattern forming, address it before it ossifies into legacy.

Module Complete