System Design (LLD)When Inheritance Goes Wrong

When Inheritance Goes Wrong

LevelIntermediate

Duration60 mins

TopicWhen Inheritance Goes Wrong

4 / 4

Signs of Inheritance Misuse — Recognizing Anti-patterns

Diagnosing Inheritance Misuse

Inheritance is often misused—not through malice or ignorance, but because it's easy to reach for. Inheritance provides code reuse with minimal syntax. Need a method from another class? Just extend it! This convenience, however, leads developers to use inheritance where other mechanisms would be more appropriate.

Recognizing inheritance misuse early is crucial. Like medical symptoms, code smells around inheritance indicate underlying design problems. Left untreated, these problems compound: the codebase becomes harder to understand, harder to change, and harder to trust.

This page catalogs the warning signs of inheritance misuse—the patterns that should trigger a design review and potentially a refactoring toward composition or other alternatives.

What You Will Learn

By the end of this page, you will be able to identify the most common signs of inheritance misuse, understand why each indicates a problem, and know what questions to ask when evaluating whether inheritance is appropriate in a given situation.

The Failed IS-A Test

The most fundamental test for inheritance is the IS-A relationship: can you truthfully say that 'B is an A' in all contexts where A is expected? When this test fails, inheritance is wrong.

Common IS-A Failures:

FailedIsA.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// WRONG: Stack is not really a Vector
// Java's actual implementation (now considered a mistake)
public class Stack<E> extends Vector<E> {
    public E push(E item) { /* ... */ }
    public E pop() { /* ... */ }
    public E peek() { /* ... */ }
}
 
// Problem: Vector exposes add(int index, element), remove(int index)
// Stack users can violate stack semantics:
Stack<String> stack = new Stack<>();
stack.push("A");
stack.push("B");
stack.add(0, "Z");  // Insert at bottom—breaks LIFO guarantee!
stack.remove(1);    // Remove from middle—also breaks LIFO
 
// The IS-A test: "A Stack IS-A Vector"? Only superficially.
// A Stack should have LIFO semantics; a Vector doesn't guarantee this.

How to Spot This:

Ask: 'Can code expecting the parent class use the child class correctly in ALL cases?' If certain inherited methods are inappropriate, dangerous, or nonsensical for the child class, the IS-A relationship doesn't hold.

Related Smells:

Subclass methods throw UnsupportedOperationException for inherited methods
Documentation says 'don't call X on this subclass'
Type checks are needed to avoid calling inherited methods

The Fix

If IS-A fails but you need the functionality, use composition: have Stack contain a Vector (or better, a List) privately, and expose only the stack operations. The Vector's inappropriate methods never become part of Stack's interface.

Inheriting for Code Reuse Only

One of the most common misuses: extending a class solely to reuse its methods, with no conceptual IS-A relationship.

Example: The Utility Inheritance Anti-pattern

ReuseOnlyInheritance.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// StringUtils has handy methods
public class StringUtils {
    public static String capitalize(String s) { /* ... */ }
    public static String reverse(String s) { /* ... */ }
    public static boolean isBlank(String s) { /* ... */ }
}
 
// BAD: Person extends StringUtils to use its methods
public class Person extends StringUtils {
    private String name;
    
    public String getFormattedName() {
        return capitalize(this.name);  // "Convenient"!
    }
}
 
// Now Person IS-A StringUtils... what does that even mean?
// StringUtils methods are static anyway; no inheritance needed.
// But Person now inherits that entire interface.
// This pollutes Person's API: person.reverse("hello") compiles!

Why This Happens:

Developers want to avoid typing StringUtils.capitalize() everywhere. Extending seems like a shortcut. But the cost is a polluted type hierarchy and nonsensical inheritance relationship.

How to Spot This:

Ask: 'Is the child class a specialized kind of the parent, or does it just need the parent's functionality?' If the answer is the latter, composition or simple method calls are correct.

Signs of Reuse-Only Inheritance

•Parent is a utility/helper class
•No polymorphism is ever used
•Parent is never used as a type for variables
•Inheritance was 'just convenient'
•Child doesn't override anything meaningful

Proper Alternatives

•Call utility methods directly (static import)
•Inject utility as a dependency
•Hold utility as a private field
•Use extension methods/mixins where available
•Create a local helper method that delegates

The Override-Everything-Or-Nothing Smell

A strong indicator of misuse: subclasses that either override nothing (pure reuse, no specialization) or override almost everything (the parent provides almost no useful behavior).

Override Nothing:

OverrideNothing.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// Subclass overrides nothing
public class Customer extends DatabaseRecord {
    // No overrides! Just uses DatabaseRecord methods directly.
    // Why inherit? Probably for save(), load(), delete() convenience.
    // But Customer IS-NOT-A DatabaseRecord conceptually.
}
 
// Better: Customer USES a DatabaseRecord (or Repository pattern)
public class Customer {
    private DatabaseRecord record;  // Composition
    
    public void save() {
        record.save(this.toMap());
    }
}

Override Nearly Everything:

OverrideEverything.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
// Subclass overrides almost all parent methods
public class Square extends Rectangle {
    @Override
    public void setWidth(int w) {
        super.setWidth(w);
        super.setHeight(w);  // Must keep width == height
    }
    
    @Override 
    public void setHeight(int h) {
        super.setWidth(h);   // Must keep width == height
        super.setHeight(h);
    }
    
    @Override
    public int getArea() {
        return getWidth() * getWidth();  // Can simplify, but must override
    }
    
    // Every method that might assume width != height must be checked...
}
 
// If you override everything, you're not inheriting behavior—
// you're fighting against it. Square doesn't behave like Rectangle.

The Square-Rectangle Problem

The classic violator: Square extends Rectangle. Mathematically, a square IS a rectangle. But behaviorally, Square cannot satisfy Rectangle's contract: Rectangle clients expect setWidth() and setHeight() to be independent operations. Square must violate this expectation.

Throwing UnsupportedOperationException for Inherited Methods

One of the clearest signs of inheritance misuse: a subclass that throws exceptions when inherited methods are called because 'that operation doesn't make sense for this subclass.'

UnsupportedOp.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
// Ostrich extends Bird, but can't fly
public class Ostrich extends Bird {
    @Override
    public void fly() {
        throw new UnsupportedOperationException(
            "Ostriches cannot fly"
        );
    }
}
 
// Or the read-only collection anti-pattern
public class ReadOnlyList<E> extends ArrayList<E> {
    @Override
    public boolean add(E element) {
        throw new UnsupportedOperationException("Read-only list");
    }
    
    @Override
    public E remove(int index) {
        throw new UnsupportedOperationException("Read-only list");
    }
    
    @Override
    public void clear() {
        throw new UnsupportedOperationException("Read-only list");
    }
    // ... must override every mutating method!
}

Why This Is Wrong:

Violates Liskov Substitution — Code expecting a Bird expects to call fly() without exceptions. Ostrich breaks this contract.
Runtime vs Compile-Time — The type system says Ostrich is a Bird. Only at runtime do you discover it can't fulfill Bird's contract. Type safety is lost.
Burden on Clients — Every client must now check type or catch exceptions before calling inherited methods. The parent's contract becomes unreliable.
API Pollution — The subclass advertises methods it doesn't support. Its interface is a lie.

The Proper Design

If some subclasses can't perform an operation, perhaps that operation shouldn't be in the parent. Consider: FlyingBird extends Bird, with Ostrich extending Bird directly (without fly()). Or use interfaces: class Ostrich extends Bird implements Runnable (but NOT Flyable).

Excessive instanceof Checks and Downcasting

When code is littered with instanceof checks and casts, it's a sign that the inheritance hierarchy isn't capturing the distinctions that matter for the code's logic.

InstanceofHell.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public void processShape(Shape shape) {
    // Red flag: different behavior based on runtime type
    if (shape instanceof Circle) {
        Circle c = (Circle) shape;
        drawCircle(c.getRadius());
    } else if (shape instanceof Rectangle) {
        Rectangle r = (Rectangle) shape;
        drawRect(r.getWidth(), r.getHeight());
    } else if (shape instanceof Triangle) {
        Triangle t = (Triangle) shape;
        drawTriangle(t.getBase(), t.getHeight());
    } else if (shape instanceof Polygon) {
        Polygon p = (Polygon) shape;
        drawPolygon(p.getPoints());  
    }
    // New shapes require modifying this method!
}
 
// What we really wanted: polymorphism
public void processShape(Shape shape) {
    shape.draw(canvas);  // Let each shape know how to draw itself
}

What instanceof Checks Indicate:

Problems Revealed by instanceof Usage

•Missing Abstract Method — If every instanceof branch calls a different subclass method, the parent should declare an abstract version of that method.
•Wrong Abstraction Level — The base class is too abstract to carry the operations clients need; subclass-specific details leak into client code.
•Incomplete Hierarchy — The hierarchy wasn't designed for the operations being performed; it's being used against its grain.
•Open/Closed Violation — Every new subclass requires modifying the instanceof ladder. The design isn't closed for modification.

The God Class at the Root

When a base class grows to contain 'everything any subclass might need,' it becomes a God Class—a massive, unfocused class that violates the Single Responsibility Principle.

GodBaseClass.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
// God class: tries to be everything to all subclasses
public abstract class AbstractEntity {
    // Fields for persistence
    protected Long id;
    protected Date createdAt, updatedAt;
    
    // Fields for auditing... why in base class?
    protected String createdBy, modifiedBy;
    
    // Serialization helpers
    protected String toJson() { /* ... */ }
    protected void fromJson(String json) { /* ... */ }
    
    // Validation framework... also here
    protected List<String> validate() { /* ... */ }
    protected boolean isValid() { /* ... */ }
    
    // Logging convenience... sure, throw it in
    protected void logInfo(String msg) { /* ... */ }
    protected void logError(String msg, Exception e) { /* ... */ }
    
    // Database operations
    public void save() { /* ... */ }
    public void delete() { /* ... */ }
    public void refresh() { /* ... */ }
    
    // Caching? Yeah, we need that too
    protected void cache() { /* ... */ }
    protected void invalidateCache() { /* ... */ }
    
    // 87 more methods...
}
 
// Every entity inherits ALL of this whether it needs it or not.
// Cannot change persistence without affecting caching.
// Cannot update logging without risking validation.

Problems with God Base Classes:

Forced Dependencies — Every subclass carries the weight of every feature in the base class
Impossible Single Responsibility — The base class has dozens of reasons to change
Modification Ripples — Any change affects all subclasses
Testing Nightmare — Testing requires mocking vast amounts of inherited infrastructure
Conceptual Confusion — New developers can't understand what the class 'is'

The Fix

Decompose the God class into focused components: a Persistence component, a Validation component, an Auditing component. Use composition: entities have these components rather than inheriting them. Each component can evolve independently.

The Inheritance Misuse Diagnostic Checklist

Use this checklist to evaluate whether inheritance is appropriate in a given design:

Inheritance Appropriateness Checklist
Question	Good Sign	Warning Sign
Does the IS-A relationship hold in all contexts?	Yes, always substitutable	Only partially, or 'conceptually'
Are you inheriting for specialization or just code reuse?	Genuine behavioral specialization	Just wanted the methods
How many methods do you override?	Few, targeted overrides	None or nearly all
Do any inherited methods throw UnsupportedOperationException?	Never	Yes, some don't apply
Do clients use instanceof checks against subclasses?	Rarely or never	Frequently, for type-specific behavior
How deep is the hierarchy?	2-3 levels	5+ levels
Can you explain what the parent class 'is' in one sentence?	Clear, focused concept	It's the base of everything...
Is composition a viable alternative?	No, inheritance is genuinely best	Yes, and it might be simpler

When in Doubt, Compose

If you're unsure whether inheritance is appropriate, default to composition. Composition can always be refactored to inheritance later if needed (rarely necessary). But refactoring from inheritance to composition is more difficult because inheritance creates tighter coupling.

Key Takeaways

Inheritance misuse creates designs that are hard to understand, hard to maintain, and hard to extend correctly. Recognizing the warning signs early allows you to refactor toward better designs before the costs compound.

Essential Takeaways

•The IS-A test must hold behaviorally, not just conceptually — Subclasses must be substitutable for parents in all contexts, not just theoretically.
•Inheriting for reuse alone is misuse — If there's no IS-A relationship, use composition to get the functionality you need.
•Override patterns reveal fit — Overriding nothing (pure reuse) or nearly everything (fighting the parent) both indicate misuse.
•UnsupportedOperationException is a design smell — If inherited methods can't be used, the inheritance relationship is wrong.
•instanceof checks indicate missing polymorphism — The hierarchy should capture the distinctions that matter; clients shouldn't need runtime type checks.
•God base classes violate SRP — Base classes should be focused, not repositories for 'everything subclasses might need'.

Module Complete

You've now completed the exploration of inheritance problems: the fragile base class problem, encapsulation violations, rigid hierarchies, and the warning signs of misuse. With this knowledge, you can evaluate inheritance decisions critically and recognize when composition or other alternatives are more appropriate. The next module will explore abstract classes—a tool for defining proper extension points when inheritance IS the right choice.

4 / 4

Loading learning content...

System Design (LLD)When Inheritance Goes Wrong

When Inheritance Goes Wrong

LevelIntermediate

Duration60 mins

TopicWhen Inheritance Goes Wrong

4 / 4

Signs of Inheritance Misuse — Recognizing Anti-patterns

Diagnosing Inheritance Misuse

This page catalogs the warning signs of inheritance misuse—the patterns that should trigger a design review and potentially a refactoring toward composition or other alternatives.

What You Will Learn

The Failed IS-A Test

The most fundamental test for inheritance is the IS-A relationship: can you truthfully say that 'B is an A' in all contexts where A is expected? When this test fails, inheritance is wrong.

Common IS-A Failures:

FailedIsA.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// WRONG: Stack is not really a Vector
// Java's actual implementation (now considered a mistake)
public class Stack<E> extends Vector<E> {
    public E push(E item) { /* ... */ }
    public E pop() { /* ... */ }
    public E peek() { /* ... */ }
}
 
// Problem: Vector exposes add(int index, element), remove(int index)
// Stack users can violate stack semantics:
Stack<String> stack = new Stack<>();
stack.push("A");
stack.push("B");
stack.add(0, "Z");  // Insert at bottom—breaks LIFO guarantee!
stack.remove(1);    // Remove from middle—also breaks LIFO
 
// The IS-A test: "A Stack IS-A Vector"? Only superficially.
// A Stack should have LIFO semantics; a Vector doesn't guarantee this.

How to Spot This:

Related Smells:

Subclass methods throw UnsupportedOperationException for inherited methods
Documentation says 'don't call X on this subclass'
Type checks are needed to avoid calling inherited methods

The Fix

Inheriting for Code Reuse Only

One of the most common misuses: extending a class solely to reuse its methods, with no conceptual IS-A relationship.

Example: The Utility Inheritance Anti-pattern

ReuseOnlyInheritance.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// StringUtils has handy methods
public class StringUtils {
    public static String capitalize(String s) { /* ... */ }
    public static String reverse(String s) { /* ... */ }
    public static boolean isBlank(String s) { /* ... */ }
}
 
// BAD: Person extends StringUtils to use its methods
public class Person extends StringUtils {
    private String name;
    
    public String getFormattedName() {
        return capitalize(this.name);  // "Convenient"!
    }
}
 
// Now Person IS-A StringUtils... what does that even mean?
// StringUtils methods are static anyway; no inheritance needed.
// But Person now inherits that entire interface.
// This pollutes Person's API: person.reverse("hello") compiles!

Why This Happens:

Developers want to avoid typing StringUtils.capitalize() everywhere. Extending seems like a shortcut. But the cost is a polluted type hierarchy and nonsensical inheritance relationship.

How to Spot This:

Ask: 'Is the child class a specialized kind of the parent, or does it just need the parent's functionality?' If the answer is the latter, composition or simple method calls are correct.

Signs of Reuse-Only Inheritance

•Parent is a utility/helper class
•No polymorphism is ever used
•Parent is never used as a type for variables
•Inheritance was 'just convenient'
•Child doesn't override anything meaningful

Proper Alternatives

•Call utility methods directly (static import)
•Inject utility as a dependency
•Hold utility as a private field
•Use extension methods/mixins where available
•Create a local helper method that delegates

The Override-Everything-Or-Nothing Smell

A strong indicator of misuse: subclasses that either override nothing (pure reuse, no specialization) or override almost everything (the parent provides almost no useful behavior).

Override Nothing:

OverrideNothing.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// Subclass overrides nothing
public class Customer extends DatabaseRecord {
    // No overrides! Just uses DatabaseRecord methods directly.
    // Why inherit? Probably for save(), load(), delete() convenience.
    // But Customer IS-NOT-A DatabaseRecord conceptually.
}
 
// Better: Customer USES a DatabaseRecord (or Repository pattern)
public class Customer {
    private DatabaseRecord record;  // Composition
    
    public void save() {
        record.save(this.toMap());
    }
}

Override Nearly Everything:

OverrideEverything.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
// Subclass overrides almost all parent methods
public class Square extends Rectangle {
    @Override
    public void setWidth(int w) {
        super.setWidth(w);
        super.setHeight(w);  // Must keep width == height
    }
    
    @Override 
    public void setHeight(int h) {
        super.setWidth(h);   // Must keep width == height
        super.setHeight(h);
    }
    
    @Override
    public int getArea() {
        return getWidth() * getWidth();  // Can simplify, but must override
    }
    
    // Every method that might assume width != height must be checked...
}
 
// If you override everything, you're not inheriting behavior—
// you're fighting against it. Square doesn't behave like Rectangle.

The Square-Rectangle Problem

Throwing UnsupportedOperationException for Inherited Methods

One of the clearest signs of inheritance misuse: a subclass that throws exceptions when inherited methods are called because 'that operation doesn't make sense for this subclass.'

UnsupportedOp.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
// Ostrich extends Bird, but can't fly
public class Ostrich extends Bird {
    @Override
    public void fly() {
        throw new UnsupportedOperationException(
            "Ostriches cannot fly"
        );
    }
}
 
// Or the read-only collection anti-pattern
public class ReadOnlyList<E> extends ArrayList<E> {
    @Override
    public boolean add(E element) {
        throw new UnsupportedOperationException("Read-only list");
    }
    
    @Override
    public E remove(int index) {
        throw new UnsupportedOperationException("Read-only list");
    }
    
    @Override
    public void clear() {
        throw new UnsupportedOperationException("Read-only list");
    }
    // ... must override every mutating method!
}

Why This Is Wrong:

Violates Liskov Substitution — Code expecting a Bird expects to call fly() without exceptions. Ostrich breaks this contract.
Runtime vs Compile-Time — The type system says Ostrich is a Bird. Only at runtime do you discover it can't fulfill Bird's contract. Type safety is lost.
Burden on Clients — Every client must now check type or catch exceptions before calling inherited methods. The parent's contract becomes unreliable.
API Pollution — The subclass advertises methods it doesn't support. Its interface is a lie.

The Proper Design

Excessive instanceof Checks and Downcasting

When code is littered with instanceof checks and casts, it's a sign that the inheritance hierarchy isn't capturing the distinctions that matter for the code's logic.

InstanceofHell.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public void processShape(Shape shape) {
    // Red flag: different behavior based on runtime type
    if (shape instanceof Circle) {
        Circle c = (Circle) shape;
        drawCircle(c.getRadius());
    } else if (shape instanceof Rectangle) {
        Rectangle r = (Rectangle) shape;
        drawRect(r.getWidth(), r.getHeight());
    } else if (shape instanceof Triangle) {
        Triangle t = (Triangle) shape;
        drawTriangle(t.getBase(), t.getHeight());
    } else if (shape instanceof Polygon) {
        Polygon p = (Polygon) shape;
        drawPolygon(p.getPoints());  
    }
    // New shapes require modifying this method!
}
 
// What we really wanted: polymorphism
public void processShape(Shape shape) {
    shape.draw(canvas);  // Let each shape know how to draw itself
}

What instanceof Checks Indicate:

Problems Revealed by instanceof Usage

•Missing Abstract Method — If every instanceof branch calls a different subclass method, the parent should declare an abstract version of that method.
•Wrong Abstraction Level — The base class is too abstract to carry the operations clients need; subclass-specific details leak into client code.
•Incomplete Hierarchy — The hierarchy wasn't designed for the operations being performed; it's being used against its grain.
•Open/Closed Violation — Every new subclass requires modifying the instanceof ladder. The design isn't closed for modification.

The God Class at the Root

When a base class grows to contain 'everything any subclass might need,' it becomes a God Class—a massive, unfocused class that violates the Single Responsibility Principle.

GodBaseClass.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
// God class: tries to be everything to all subclasses
public abstract class AbstractEntity {
    // Fields for persistence
    protected Long id;
    protected Date createdAt, updatedAt;
    
    // Fields for auditing... why in base class?
    protected String createdBy, modifiedBy;
    
    // Serialization helpers
    protected String toJson() { /* ... */ }
    protected void fromJson(String json) { /* ... */ }
    
    // Validation framework... also here
    protected List<String> validate() { /* ... */ }
    protected boolean isValid() { /* ... */ }
    
    // Logging convenience... sure, throw it in
    protected void logInfo(String msg) { /* ... */ }
    protected void logError(String msg, Exception e) { /* ... */ }
    
    // Database operations
    public void save() { /* ... */ }
    public void delete() { /* ... */ }
    public void refresh() { /* ... */ }
    
    // Caching? Yeah, we need that too
    protected void cache() { /* ... */ }
    protected void invalidateCache() { /* ... */ }
    
    // 87 more methods...
}
 
// Every entity inherits ALL of this whether it needs it or not.
// Cannot change persistence without affecting caching.
// Cannot update logging without risking validation.

Problems with God Base Classes:

Forced Dependencies — Every subclass carries the weight of every feature in the base class
Impossible Single Responsibility — The base class has dozens of reasons to change
Modification Ripples — Any change affects all subclasses
Testing Nightmare — Testing requires mocking vast amounts of inherited infrastructure
Conceptual Confusion — New developers can't understand what the class 'is'

The Fix

The Inheritance Misuse Diagnostic Checklist

Use this checklist to evaluate whether inheritance is appropriate in a given design:

Inheritance Appropriateness Checklist
Question	Good Sign	Warning Sign
Does the IS-A relationship hold in all contexts?	Yes, always substitutable	Only partially, or 'conceptually'
Are you inheriting for specialization or just code reuse?	Genuine behavioral specialization	Just wanted the methods
How many methods do you override?	Few, targeted overrides	None or nearly all
Do any inherited methods throw UnsupportedOperationException?	Never	Yes, some don't apply
Do clients use instanceof checks against subclasses?	Rarely or never	Frequently, for type-specific behavior
How deep is the hierarchy?	2-3 levels	5+ levels
Can you explain what the parent class 'is' in one sentence?	Clear, focused concept	It's the base of everything...
Is composition a viable alternative?	No, inheritance is genuinely best	Yes, and it might be simpler

When in Doubt, Compose

Key Takeaways

Essential Takeaways

•The IS-A test must hold behaviorally, not just conceptually — Subclasses must be substitutable for parents in all contexts, not just theoretically.
•Inheriting for reuse alone is misuse — If there's no IS-A relationship, use composition to get the functionality you need.
•Override patterns reveal fit — Overriding nothing (pure reuse) or nearly everything (fighting the parent) both indicate misuse.
•UnsupportedOperationException is a design smell — If inherited methods can't be used, the inheritance relationship is wrong.
•instanceof checks indicate missing polymorphism — The hierarchy should capture the distinctions that matter; clients shouldn't need runtime type checks.
•God base classes violate SRP — Base classes should be focused, not repositories for 'everything subclasses might need'.

Module Complete

4 / 4