Has A Vs Is A Relationships - Learning Module

Loading content...

0/246

Common Relationship Mistakes

Learning from Failure

Understanding IS-A and HAS-A in theory is one thing; avoiding relationship mistakes in practice is another. Even experienced developers fall into predictable traps when designing class relationships—not from ignorance, but from subtle pressures: time constraints, superficial similarities, or the seductive promise of "code reuse."

This page catalogs the most common relationship mistakes, teaching you to recognize their symptoms, understand their consequences, and apply proven remediation strategies. By studying these anti-patterns, you'll develop the pattern recognition to avoid them in your own designs.

What You Will Learn

By the end of this page, you will recognize the most common IS-A vs HAS-A mistakes, understand why they occur and what damage they cause, and know how to refactor from incorrect relationships to correct ones.

Mistake #1: Inheritance for Code Reuse

The Pattern:

Two classes share some code, so a developer makes one inherit from the other—even though there's no genuine IS-A relationship.

Why It Happens:

Inheritance provides code reuse "for free"—write it once in the parent, get it automatically in the child. This is tempting, especially under time pressure. But it conflates two separate concerns: code reuse and type relationships.

The Damage:

Semantic Confusion: The type hierarchy no longer reflects reality
Unwanted Inheritance: The child inherits ALL parent behavior, including inappropriate parts
Tight Coupling: Changes to the parent ripple unexpectedly to children
Substitution Failures: Code expecting the parent breaks with the child

inheritance-for-reuse.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
// THE MISTAKE: Inheriting for code reuse
// Stack doesn't actually have an IS-A relationship with ArrayList
public class Stack<T> extends ArrayList<T> {
    public void push(T item) {
        add(item);  // Reusing ArrayList.add()
    }
    
    public T pop() {
        if (isEmpty()) throw new EmptyStackException();
        return remove(size() - 1);  // Reusing ArrayList.remove()
    }
    
    public T peek() {
        if (isEmpty()) throw new EmptyStackException();
        return get(size() - 1);  // Reusing ArrayList.get()
    }
}
 
// PROBLEMS:
Stack<String> stack = new Stack<>();
stack.push("A");
stack.push("B");
stack.push("C");
 
// All these work but VIOLATE stack semantics:
stack.add(0, "X");        // ArrayList method - violates LIFO
stack.get(1);             // Random access - not a stack operation
stack.remove(0);          // Remove from middle - violates LIFO
stack.set(1, "Z");        // Modify middle - violates LIFO
 
// THE FIX: Use composition (HAS-A)
public class Stack<T> {
    private final List<T> elements = new ArrayList<>();  // HAS-A, not IS-A
    
    public void push(T item) {
        elements.add(item);
    }
    
    public T pop() {
        if (isEmpty()) throw new EmptyStackException();
        return elements.remove(elements.size() - 1);
    }
    
    public T peek() {
        if (isEmpty()) throw new EmptyStackException();
        return elements.get(elements.size() - 1);
    }
    
    public boolean isEmpty() {
        return elements.isEmpty();
    }
    
    public int size() {
        return elements.size();
    }
    
    // No get(), add(index), set(), remove(index) exposed!
    // Only stack operations are available.
}

The Fix

Replace inheritance with composition. Create a private field for the "reused" class and delegate only the specific behaviors you need. This gives you reuse without polluting your public interface or creating false type relationships.

Mistake #2: Inheritance for Changeable Roles

The Pattern:

A developer models roles or states that can change as inheritance hierarchies.

Why It Happens:

"A Manager IS A Employee" sounds correct in English, leading to class Manager extends Employee. But this ignores that a Person might transition between roles.

The Damage:

Impossibility of Role Transitions: Objects can't change their class at runtime
Combinatorial Explosion: What about ManagerEngineer? PartTimeStudent? SeniorManagerWithAdminPrivileges?
Rigid Data Models: Database records can't easily change type
Testing Complexity: Can't easily test role transitions

inheritance-for-roles.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
// THE MISTAKE: Roles as inheritance
public class Employee {
    private String name;
    private BigDecimal salary;
}
 
public class Manager extends Employee {
    private List<Employee> directReports;
    
    public void addReport(Employee emp) { directReports.add(emp); }
}
 
public class Engineer extends Employee {
    private String specialization;
    private List<String> certifications;
}
 
// PROBLEMS:
Engineer alice = new Engineer("Alice", "Backend");
// Alice gets promoted to Engineering Manager...
// Now what? You can't "change" alice to a Manager!
 
// Terrible workaround:
Manager aliceAsManager = new Manager();
aliceAsManager.setName(alice.getName());
aliceAsManager.setSalary(alice.getSalary());
// Lost: certifications, specialization, alice's identity in other references!
 
// THE FIX: Roles as composition
public class Employee {
    private final String id;
    private String name;
    private BigDecimal salary;
    private Set<Role> roles = new HashSet<>();  // HAS roles
    
    public void addRole(Role role) { roles.add(role); }
    public void removeRole(Role role) { roles.remove(role); }
    
    public <T extends Role> Optional<T> getRole(Class<T> roleType) {
        return roles.stream()
            .filter(roleType::isInstance)
            .map(roleType::cast)
            .findFirst();
    }
    
    public boolean hasRole(Class<? extends Role> roleType) {
        return roles.stream().anyMatch(roleType::isInstance);
    }
}
 
public interface Role {}
 
public class ManagerRole implements Role {
    private List<String> directReportIds;
}
 
public class EngineerRole implements Role {
    private String specialization;
    private List<String> certifications;
}
 
// Now transitions are trivial:
Employee alice = new Employee("Alice");
alice.addRole(new EngineerRole("Backend", List.of("AWS", "K8s")));
 
// Promotion to Manager:
alice.addRole(new ManagerRole(List.of("bob-id", "carol-id")));
// Alice is now both an Engineer and a Manager!
 
// Later, if Alice moves to pure management:
alice.getRole(EngineerRole.class).ifPresent(alice::removeRole);

Signs of This Mistake

•Classes named with suffixes like 'Type', 'Kind', 'Status', 'Level'
•Comments like "promote user to admin" that can't actually be implemented cleanly
•Multiple inheritance hierarchies that overlap (FullTimeManager, PartTimeManager...)
•Database columns like 'employee_type' that cause JOIN complexity
•Business logic scattered across type-specific subclasses

Mistake #3: Violating Liskov Substitution

The Pattern:

A subclass is created that looks like an IS-A relationship syntactically, but violates the behavioral contract of the parent class.

Why It Happens:

Developers focus on syntax (method signatures) rather than semantics (behavioral contracts). The type system happily compiles code that is semantically broken.

The Damage:

Runtime Surprises: Code that worked with parent instances fails mysteriously with child instances
Defensive Code Proliferation: Clients add type checks and special cases
Testing Gaps: Parent-level tests pass, but real usage fails
Design Erosion: Each LSP violation invites more violations

lsp-violation.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
// THE MISTAKE: Subclass that violates parent's contract
public class Bird {
    public void fly() {
        System.out.println("Flying through the air");
    }
    
    public void eat() {
        System.out.println("Eating food");
    }
}
 
public class Penguin extends Bird {
    @Override
    public void fly() {
        throw new UnsupportedOperationException("Penguins can't fly!");
    }
}
 
// PROBLEM: Client code that depends on Bird contract breaks
public class BirdSanctuary {
    public void releaseBirds(List<Bird> birds) {
        for (Bird bird : birds) {
            bird.fly();  // BOOM! UnsupportedOperationException for penguins
        }
    }
}
 
// THE FIX: Rethink the hierarchy
// Option 1: Separate hierarchies
public interface Animal {
    void eat();
}
 
public interface FlyingAnimal extends Animal {
    void fly();
}
 
public class Sparrow implements FlyingAnimal {
    public void fly() { /* ... */ }
    public void eat() { /* ... */ }
}
 
public class Penguin implements Animal {  // Does NOT implement FlyingAnimal
    public void eat() { /* ... */ }
    public void swim() { /* ... */ }  // Penguin-specific
}
 
// Option 2: Capability-based composition
public interface MovementCapability {}
 
public class FlyingCapability implements MovementCapability {
    public void fly() { /* ... */ }
}
 
public class SwimmingCapability implements MovementCapability {
    public void swim() { /* ... */ }
}
 
public class Bird {
    private final List<MovementCapability> capabilities;
    
    public Bird(MovementCapability... caps) {
        this.capabilities = Arrays.asList(caps);
    }
    
    public <T extends MovementCapability> Optional<T> getCapability(Class<T> type) {
        return capabilities.stream()
            .filter(type::isInstance)
            .map(type::cast)
            .findFirst();
    }
}
 
// Now:
Bird sparrow = new Bird(new FlyingCapability(), new WalkingCapability());
Bird penguin = new Bird(new SwimmingCapability(), new WalkingCapability());
// No false promises!

The instanceof Smell

When you see if (bird instanceof Penguin) { /* skip flying */ } in client code, that's a red flag. Clients shouldn't need to know about specific subtypes—that defeats the purpose of polymorphism. This pattern indicates an LSP violation in the hierarchy.

Mistake #4: Excessively Deep Hierarchies

The Pattern:

An inheritance hierarchy grows to 4, 5, 6+ levels deep, with each level adding small increments of behavior.

Why It Happens:

Developers keep specializing: Animal → Mammal → Canine → Dog → Retriever → GoldenRetriever → EnglishGoldenRetriever. Each step seems reasonable in isolation.

The Damage:

Comprehension Overhead: Understanding a class requires tracing through many ancestors
Fragile Changes: Modifying any ancestor can break all descendants
Rigid Structure: Adding cross-cutting behavior requires touching many classes
Initialization Complexity: Constructor chains become intricate and error-prone
Testing Difficulty: Must understand ancestor setup to test child classes

Hierarchy Depth Guidelines
Depth	Assessment	Recommendation
1-2 levels	Healthy	Continue as appropriate
3 levels	Caution	Question if all levels are necessary
4+ levels	Red flag	Refactor—use composition or traits
5+ levels	Anti-pattern	Almost certainly wrong; requires immediate refactoring

deep-hierarchy-refactor.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
// THE MISTAKE: 5-level hierarchy
public class Component { }
public class Container extends Component { }
public class Window extends Container { }
public class Dialog extends Window { }
public class FormDialog extends Dialog { }
public class ValidationFormDialog extends FormDialog { }
 
// To understand ValidationFormDialog, you must trace through 5 parents!
 
// THE FIX: Flatten with composition
public class Dialog {
    private final WindowBehavior windowBehavior;  // HAS-A
    private final ContainerBehavior containerBehavior;  // HAS-A
    
    private final DialogStyle style;
    private final FormHandler formHandler;  // HAS-A for form behavior
    private final Validator validator;  // HAS-A for validation behavior
    
    public Dialog(DialogStyle style, FormHandler formHandler, Validator validator) {
        this.windowBehavior = new WindowBehavior();
        this.containerBehavior = new ContainerBehavior();
        this.style = style;
        this.formHandler = formHandler;
        this.validator = validator;
    }
    
    // Expose only what's needed
    public void show() {
        windowBehavior.makeVisible();
    }
    
    public void submit() {
        if (validator.validate(formHandler.getData())) {
            formHandler.submit();
            close();
        }
    }
    
    // Factory methods for common configurations
    public static Dialog simpleDialog() {
        return new Dialog(DialogStyle.SIMPLE, null, Validator.NONE);
    }
    
    public static Dialog formDialog(FormHandler handler) {
        return new Dialog(DialogStyle.FORM, handler, Validator.NONE);
    }
    
    public static Dialog validatedFormDialog(FormHandler handler, Validator validator) {
        return new Dialog(DialogStyle.FORM, handler, validator);
    }
}
 
// Now: 1-level class with composed behaviors
// Easy to understand, easy to test, easy to extend

The Rule of Three

If your hierarchy exceeds 3 levels, pause and ask: 'Can I express these variations through composition instead?' Often, what looks like a classification hierarchy is actually a combination of orthogonal features that compose better than they inherit.

Mistake #5: Abstract Classes as Grab-Bags

The Pattern:

An abstract base class accumulates shared utility code, becoming a grab-bag of unrelated functionality that all subclasses inherit.

Why It Happens:

"All our services need logging, metrics, and database access. Let's put it in a BaseService and extend from there." Convenient—but it violates the Single Responsibility Principle and creates hidden coupling.

The Damage:

Forced Dependencies: All subclasses depend on utilities they may not need
Testing Complexity: Testing one service drags in logging, metrics, database setup
Violation of ISP: Subclasses inherit interface pollution
Modification Ripples: Changing the base class affects all services

abstract-grab-bag.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
// THE MISTAKE: Abstract class as grab-bag
public abstract class BaseService {
    protected final Logger logger = LoggerFactory.getLogger(getClass());
    protected final MetricsRegistry metrics;
    protected final DataSource dataSource;
    protected final Cache cache;
    protected final HttpClient httpClient;
    
    protected BaseService(MetricsRegistry metrics, DataSource ds, 
                          Cache cache, HttpClient client) {
        this.metrics = metrics;
        this.dataSource = ds;
        this.cache = cache;
        this.httpClient = client;
    }
    
    // "Helpful" utility methods
    protected void logInfo(String msg) { logger.info(msg); }
    protected void recordMetric(String name, double value) { /* ... */ }
    protected Connection getConnection() throws SQLException { /* ... */ }
    protected <T> T cacheGet(String key, Class<T> type) { /* ... */ }
    protected String httpGet(String url) { /* ... */ }
}
 
public class UserService extends BaseService {
    // Only needs dataSource, but forced to accept cache, httpClient too!
}
 
public class NotificationService extends BaseService {
    // Only needs httpClient, but forced to accept dataSource, cache too!
}
 
// THE FIX: Composition with explicit dependencies
public class UserService {
    private final Logger logger = LoggerFactory.getLogger(UserService.class);
    private final UserRepository userRepository;  // Only what's needed
    private final MetricsRegistry metrics;  // Only what's needed
    
    public UserService(UserRepository userRepository, MetricsRegistry metrics) {
        this.userRepository = userRepository;
        this.metrics = metrics;
    }
}
 
public class NotificationService {
    private final Logger logger = LoggerFactory.getLogger(NotificationService.class);
    private final NotificationProvider provider;  // Only what's needed
    
    public NotificationService(NotificationProvider provider) {
        this.provider = provider;
    }
}
 
// Each service declares exactly what it needs
// No hidden dependencies, no forced baggage
// Easy to test with minimal mocking

When Abstract Base Classes Are Appropriate

•Template method pattern — When there's a genuine algorithm skeleton with pluggable steps
•Shared domain logic — When all subclasses truly share the same domain behavior
•Framework hooks — When you're providing extensibility points for known variation
•Type taxonomy — When there's a real IS-A classification that benefits from shared implementation

Detecting Relationship Mistakes

How do you know if you've made a relationship mistake? Watch for these symptoms in existing code:

Relationship Mistake Symptoms
Symptom	Likely Mistake	Verification	Fix Direction
`instanceof` checks in client code	LSP violation or wrong IS-A	Check if substitution truly works	Redesign hierarchy or use composition
Methods that throw `UnsupportedOperationException`	LSP violation	Subclass can't fulfill parent contract	Split interface or use composition
Subclass that ignores most parent methods	IS-A for code reuse	Check if IS-A sentence makes sense	Convert to HAS-A with delegation
Difficulty writing tests without mocking everything	Abstract grab-bag or deep hierarchy	Check dependency count	Flatten hierarchy, inject dependencies
'Type' or 'Kind' enums with switch statements	Missed polymorphism or wrong hierarchy	Check if types should be classes	Extract to separate classes or composition
Can't add feature without modifying base class	Too much in base, not enough composition	Check if feature is shared by all subclasses	Move to composition, use decorator

Code Review Checklist for Relationships:

When reviewing new inheritance:

✓ Does the sentence test pass? (A Child IS A Parent)
✓ Does the substitution test pass? (Child works wherever Parent expected)
✓ Is the relationship permanent? (Not a changeable role)
✓ Are all parent methods relevant to child? (100% rule)
✓ Is the hierarchy shallow? (≤ 3 levels)
✓ Is the parent designed for extension? (Not a grab-bag)

If any answer is "no," require refactoring before merge.

Refactoring from Wrong to Right Relationships

When you've identified a relationship mistake, here are proven refactoring strategies:

Strategy 1: Replace Inheritance with Delegation

For the IS-A-for-code-reuse mistake:

Create a private field of the former parent type
Implement the public interface of the former child
Delegate each method to the composed object
Remove the inheritance relationship
Adjust client code (usually minimal changes if you preserve the interface)

Strategy 2: Extract Role Objects

For the inheritance-of-changeable-roles mistake:

Identify which parent properties represent roles vs. identity
Create Role classes/interfaces for the role aspects
Add a collection of roles to the base class
Migrate role-specific behavior to role classes
Eliminate the inheritance hierarchy for roles

Strategy 3: Flatten Hierarchy

For excessively deep hierarchies:

Identify which levels represent true specialization vs. feature accumulation
Extract accumulated features into composed objects
Collapse intermediate levels that don't represent genuine classifications
Use interfaces for type relationships, composition for shared behavior

Refactoring Risk

Changing inheritance relationships is high-risk refactoring. Ensure comprehensive test coverage before starting. Make changes incrementally—one step at a time—and verify tests pass at each step. Consider using the Strangler pattern for large hierarchies.

Prior to Refactoring:

Add Tests: Ensure existing behavior is captured in tests
Identify Clients: Find all code that uses the hierarchy
Plan Increments: Break the refactoring into small, reversible steps
Communicate: Inform the team about the planned changes
Create Parallel Structure: Build the new design alongside the old before switching

Summary: Common Relationship Mistakes

We've catalogued the most common IS-A vs HAS-A mistakes, their causes, symptoms, and remedies. Let's consolidate:

Key Takeaways

•Inheritance for code reuse — Use composition instead; delegate to contained objects
•Inheritance for changeable roles — Model roles as composed objects that can be added/removed
•LSP violations — Rethink the hierarchy or use composition for varying capabilities
•Deep hierarchies — Flatten with composition; aim for ≤ 3 levels
•Abstract grab-bags — Inject dependencies explicitly; don't force shared utilities through inheritance
•Watch for symptoms — instanceof, UnsupportedOperationException, testing difficulty, type enums
•Refactor carefully — Add tests first, change incrementally, verify at each step

Module Complete:

You now have a complete understanding of IS-A vs HAS-A relationships:

IS-A (Page 1): Inheritance as type identity and substitutability
HAS-A (Page 2): Composition as containment and delegation
Testing (Page 3): A systematic framework for choosing the right relationship
Mistakes (Page 4): Common errors and how to avoid or fix them

With this knowledge, you can design class relationships that are semantically correct, flexible, and maintainable—avoiding the traps that plague many codebases.

Module Complete

You've mastered the critical distinction between IS-A and HAS-A relationships. You can now recognize when each applies, test your designs systematically, and avoid the common mistakes that lead to fragile, rigid hierarchies. Next, you'll learn the famous 'Favor Composition Over Inheritance' principle and when it does—and doesn't—apply.

Common Relationship Mistakes

Learning from Failure

What You Will Learn

Mistake #1: Inheritance for Code Reuse

The Pattern:

Two classes share some code, so a developer makes one inherit from the other—even though there's no genuine IS-A relationship.

Why It Happens:

The Damage:

Semantic Confusion: The type hierarchy no longer reflects reality
Unwanted Inheritance: The child inherits ALL parent behavior, including inappropriate parts
Tight Coupling: Changes to the parent ripple unexpectedly to children
Substitution Failures: Code expecting the parent breaks with the child

inheritance-for-reuse.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
// THE MISTAKE: Inheriting for code reuse
// Stack doesn't actually have an IS-A relationship with ArrayList
public class Stack<T> extends ArrayList<T> {
    public void push(T item) {
        add(item);  // Reusing ArrayList.add()
    }
    
    public T pop() {
        if (isEmpty()) throw new EmptyStackException();
        return remove(size() - 1);  // Reusing ArrayList.remove()
    }
    
    public T peek() {
        if (isEmpty()) throw new EmptyStackException();
        return get(size() - 1);  // Reusing ArrayList.get()
    }
}
 
// PROBLEMS:
Stack<String> stack = new Stack<>();
stack.push("A");
stack.push("B");
stack.push("C");
 
// All these work but VIOLATE stack semantics:
stack.add(0, "X");        // ArrayList method - violates LIFO
stack.get(1);             // Random access - not a stack operation
stack.remove(0);          // Remove from middle - violates LIFO
stack.set(1, "Z");        // Modify middle - violates LIFO
 
// THE FIX: Use composition (HAS-A)
public class Stack<T> {
    private final List<T> elements = new ArrayList<>();  // HAS-A, not IS-A
    
    public void push(T item) {
        elements.add(item);
    }
    
    public T pop() {
        if (isEmpty()) throw new EmptyStackException();
        return elements.remove(elements.size() - 1);
    }
    
    public T peek() {
        if (isEmpty()) throw new EmptyStackException();
        return elements.get(elements.size() - 1);
    }
    
    public boolean isEmpty() {
        return elements.isEmpty();
    }
    
    public int size() {
        return elements.size();
    }
    
    // No get(), add(index), set(), remove(index) exposed!
    // Only stack operations are available.
}

The Fix

Mistake #2: Inheritance for Changeable Roles

The Pattern:

A developer models roles or states that can change as inheritance hierarchies.

Why It Happens:

"A Manager IS A Employee" sounds correct in English, leading to class Manager extends Employee. But this ignores that a Person might transition between roles.

The Damage:

Impossibility of Role Transitions: Objects can't change their class at runtime
Combinatorial Explosion: What about ManagerEngineer? PartTimeStudent? SeniorManagerWithAdminPrivileges?
Rigid Data Models: Database records can't easily change type
Testing Complexity: Can't easily test role transitions

inheritance-for-roles.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
// THE MISTAKE: Roles as inheritance
public class Employee {
    private String name;
    private BigDecimal salary;
}
 
public class Manager extends Employee {
    private List<Employee> directReports;
    
    public void addReport(Employee emp) { directReports.add(emp); }
}
 
public class Engineer extends Employee {
    private String specialization;
    private List<String> certifications;
}
 
// PROBLEMS:
Engineer alice = new Engineer("Alice", "Backend");
// Alice gets promoted to Engineering Manager...
// Now what? You can't "change" alice to a Manager!
 
// Terrible workaround:
Manager aliceAsManager = new Manager();
aliceAsManager.setName(alice.getName());
aliceAsManager.setSalary(alice.getSalary());
// Lost: certifications, specialization, alice's identity in other references!
 
// THE FIX: Roles as composition
public class Employee {
    private final String id;
    private String name;
    private BigDecimal salary;
    private Set<Role> roles = new HashSet<>();  // HAS roles
    
    public void addRole(Role role) { roles.add(role); }
    public void removeRole(Role role) { roles.remove(role); }
    
    public <T extends Role> Optional<T> getRole(Class<T> roleType) {
        return roles.stream()
            .filter(roleType::isInstance)
            .map(roleType::cast)
            .findFirst();
    }
    
    public boolean hasRole(Class<? extends Role> roleType) {
        return roles.stream().anyMatch(roleType::isInstance);
    }
}
 
public interface Role {}
 
public class ManagerRole implements Role {
    private List<String> directReportIds;
}
 
public class EngineerRole implements Role {
    private String specialization;
    private List<String> certifications;
}
 
// Now transitions are trivial:
Employee alice = new Employee("Alice");
alice.addRole(new EngineerRole("Backend", List.of("AWS", "K8s")));
 
// Promotion to Manager:
alice.addRole(new ManagerRole(List.of("bob-id", "carol-id")));
// Alice is now both an Engineer and a Manager!
 
// Later, if Alice moves to pure management:
alice.getRole(EngineerRole.class).ifPresent(alice::removeRole);

Signs of This Mistake

•Classes named with suffixes like 'Type', 'Kind', 'Status', 'Level'
•Comments like "promote user to admin" that can't actually be implemented cleanly
•Multiple inheritance hierarchies that overlap (FullTimeManager, PartTimeManager...)
•Database columns like 'employee_type' that cause JOIN complexity
•Business logic scattered across type-specific subclasses

Mistake #3: Violating Liskov Substitution

The Pattern:

A subclass is created that looks like an IS-A relationship syntactically, but violates the behavioral contract of the parent class.

Why It Happens:

Developers focus on syntax (method signatures) rather than semantics (behavioral contracts). The type system happily compiles code that is semantically broken.

The Damage:

Runtime Surprises: Code that worked with parent instances fails mysteriously with child instances
Defensive Code Proliferation: Clients add type checks and special cases
Testing Gaps: Parent-level tests pass, but real usage fails
Design Erosion: Each LSP violation invites more violations

lsp-violation.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
// THE MISTAKE: Subclass that violates parent's contract
public class Bird {
    public void fly() {
        System.out.println("Flying through the air");
    }
    
    public void eat() {
        System.out.println("Eating food");
    }
}
 
public class Penguin extends Bird {
    @Override
    public void fly() {
        throw new UnsupportedOperationException("Penguins can't fly!");
    }
}
 
// PROBLEM: Client code that depends on Bird contract breaks
public class BirdSanctuary {
    public void releaseBirds(List<Bird> birds) {
        for (Bird bird : birds) {
            bird.fly();  // BOOM! UnsupportedOperationException for penguins
        }
    }
}
 
// THE FIX: Rethink the hierarchy
// Option 1: Separate hierarchies
public interface Animal {
    void eat();
}
 
public interface FlyingAnimal extends Animal {
    void fly();
}
 
public class Sparrow implements FlyingAnimal {
    public void fly() { /* ... */ }
    public void eat() { /* ... */ }
}
 
public class Penguin implements Animal {  // Does NOT implement FlyingAnimal
    public void eat() { /* ... */ }
    public void swim() { /* ... */ }  // Penguin-specific
}
 
// Option 2: Capability-based composition
public interface MovementCapability {}
 
public class FlyingCapability implements MovementCapability {
    public void fly() { /* ... */ }
}
 
public class SwimmingCapability implements MovementCapability {
    public void swim() { /* ... */ }
}
 
public class Bird {
    private final List<MovementCapability> capabilities;
    
    public Bird(MovementCapability... caps) {
        this.capabilities = Arrays.asList(caps);
    }
    
    public <T extends MovementCapability> Optional<T> getCapability(Class<T> type) {
        return capabilities.stream()
            .filter(type::isInstance)
            .map(type::cast)
            .findFirst();
    }
}
 
// Now:
Bird sparrow = new Bird(new FlyingCapability(), new WalkingCapability());
Bird penguin = new Bird(new SwimmingCapability(), new WalkingCapability());
// No false promises!

The instanceof Smell

Mistake #4: Excessively Deep Hierarchies

The Pattern:

An inheritance hierarchy grows to 4, 5, 6+ levels deep, with each level adding small increments of behavior.

Why It Happens:

Developers keep specializing: Animal → Mammal → Canine → Dog → Retriever → GoldenRetriever → EnglishGoldenRetriever. Each step seems reasonable in isolation.

The Damage:

Comprehension Overhead: Understanding a class requires tracing through many ancestors
Fragile Changes: Modifying any ancestor can break all descendants
Rigid Structure: Adding cross-cutting behavior requires touching many classes
Initialization Complexity: Constructor chains become intricate and error-prone
Testing Difficulty: Must understand ancestor setup to test child classes

Hierarchy Depth Guidelines
Depth	Assessment	Recommendation
1-2 levels	Healthy	Continue as appropriate
3 levels	Caution	Question if all levels are necessary
4+ levels	Red flag	Refactor—use composition or traits
5+ levels	Anti-pattern	Almost certainly wrong; requires immediate refactoring

deep-hierarchy-refactor.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
// THE MISTAKE: 5-level hierarchy
public class Component { }
public class Container extends Component { }
public class Window extends Container { }
public class Dialog extends Window { }
public class FormDialog extends Dialog { }
public class ValidationFormDialog extends FormDialog { }
 
// To understand ValidationFormDialog, you must trace through 5 parents!
 
// THE FIX: Flatten with composition
public class Dialog {
    private final WindowBehavior windowBehavior;  // HAS-A
    private final ContainerBehavior containerBehavior;  // HAS-A
    
    private final DialogStyle style;
    private final FormHandler formHandler;  // HAS-A for form behavior
    private final Validator validator;  // HAS-A for validation behavior
    
    public Dialog(DialogStyle style, FormHandler formHandler, Validator validator) {
        this.windowBehavior = new WindowBehavior();
        this.containerBehavior = new ContainerBehavior();
        this.style = style;
        this.formHandler = formHandler;
        this.validator = validator;
    }
    
    // Expose only what's needed
    public void show() {
        windowBehavior.makeVisible();
    }
    
    public void submit() {
        if (validator.validate(formHandler.getData())) {
            formHandler.submit();
            close();
        }
    }
    
    // Factory methods for common configurations
    public static Dialog simpleDialog() {
        return new Dialog(DialogStyle.SIMPLE, null, Validator.NONE);
    }
    
    public static Dialog formDialog(FormHandler handler) {
        return new Dialog(DialogStyle.FORM, handler, Validator.NONE);
    }
    
    public static Dialog validatedFormDialog(FormHandler handler, Validator validator) {
        return new Dialog(DialogStyle.FORM, handler, validator);
    }
}
 
// Now: 1-level class with composed behaviors
// Easy to understand, easy to test, easy to extend

The Rule of Three

Mistake #5: Abstract Classes as Grab-Bags

The Pattern:

An abstract base class accumulates shared utility code, becoming a grab-bag of unrelated functionality that all subclasses inherit.

Why It Happens:

The Damage:

Forced Dependencies: All subclasses depend on utilities they may not need
Testing Complexity: Testing one service drags in logging, metrics, database setup
Violation of ISP: Subclasses inherit interface pollution
Modification Ripples: Changing the base class affects all services

abstract-grab-bag.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
// THE MISTAKE: Abstract class as grab-bag
public abstract class BaseService {
    protected final Logger logger = LoggerFactory.getLogger(getClass());
    protected final MetricsRegistry metrics;
    protected final DataSource dataSource;
    protected final Cache cache;
    protected final HttpClient httpClient;
    
    protected BaseService(MetricsRegistry metrics, DataSource ds, 
                          Cache cache, HttpClient client) {
        this.metrics = metrics;
        this.dataSource = ds;
        this.cache = cache;
        this.httpClient = client;
    }
    
    // "Helpful" utility methods
    protected void logInfo(String msg) { logger.info(msg); }
    protected void recordMetric(String name, double value) { /* ... */ }
    protected Connection getConnection() throws SQLException { /* ... */ }
    protected <T> T cacheGet(String key, Class<T> type) { /* ... */ }
    protected String httpGet(String url) { /* ... */ }
}
 
public class UserService extends BaseService {
    // Only needs dataSource, but forced to accept cache, httpClient too!
}
 
public class NotificationService extends BaseService {
    // Only needs httpClient, but forced to accept dataSource, cache too!
}
 
// THE FIX: Composition with explicit dependencies
public class UserService {
    private final Logger logger = LoggerFactory.getLogger(UserService.class);
    private final UserRepository userRepository;  // Only what's needed
    private final MetricsRegistry metrics;  // Only what's needed
    
    public UserService(UserRepository userRepository, MetricsRegistry metrics) {
        this.userRepository = userRepository;
        this.metrics = metrics;
    }
}
 
public class NotificationService {
    private final Logger logger = LoggerFactory.getLogger(NotificationService.class);
    private final NotificationProvider provider;  // Only what's needed
    
    public NotificationService(NotificationProvider provider) {
        this.provider = provider;
    }
}
 
// Each service declares exactly what it needs
// No hidden dependencies, no forced baggage
// Easy to test with minimal mocking

When Abstract Base Classes Are Appropriate

•Template method pattern — When there's a genuine algorithm skeleton with pluggable steps
•Shared domain logic — When all subclasses truly share the same domain behavior
•Framework hooks — When you're providing extensibility points for known variation
•Type taxonomy — When there's a real IS-A classification that benefits from shared implementation

Detecting Relationship Mistakes

How do you know if you've made a relationship mistake? Watch for these symptoms in existing code:

Relationship Mistake Symptoms
Symptom	Likely Mistake	Verification	Fix Direction
`instanceof` checks in client code	LSP violation or wrong IS-A	Check if substitution truly works	Redesign hierarchy or use composition
Methods that throw `UnsupportedOperationException`	LSP violation	Subclass can't fulfill parent contract	Split interface or use composition
Subclass that ignores most parent methods	IS-A for code reuse	Check if IS-A sentence makes sense	Convert to HAS-A with delegation
Difficulty writing tests without mocking everything	Abstract grab-bag or deep hierarchy	Check dependency count	Flatten hierarchy, inject dependencies
'Type' or 'Kind' enums with switch statements	Missed polymorphism or wrong hierarchy	Check if types should be classes	Extract to separate classes or composition
Can't add feature without modifying base class	Too much in base, not enough composition	Check if feature is shared by all subclasses	Move to composition, use decorator

Code Review Checklist for Relationships:

When reviewing new inheritance:

✓ Does the sentence test pass? (A Child IS A Parent)
✓ Does the substitution test pass? (Child works wherever Parent expected)
✓ Is the relationship permanent? (Not a changeable role)
✓ Are all parent methods relevant to child? (100% rule)
✓ Is the hierarchy shallow? (≤ 3 levels)
✓ Is the parent designed for extension? (Not a grab-bag)

If any answer is "no," require refactoring before merge.

Refactoring from Wrong to Right Relationships

When you've identified a relationship mistake, here are proven refactoring strategies:

Strategy 1: Replace Inheritance with Delegation

For the IS-A-for-code-reuse mistake:

Create a private field of the former parent type
Implement the public interface of the former child
Delegate each method to the composed object
Remove the inheritance relationship
Adjust client code (usually minimal changes if you preserve the interface)

Strategy 2: Extract Role Objects

For the inheritance-of-changeable-roles mistake:

Identify which parent properties represent roles vs. identity
Create Role classes/interfaces for the role aspects
Add a collection of roles to the base class
Migrate role-specific behavior to role classes
Eliminate the inheritance hierarchy for roles

Strategy 3: Flatten Hierarchy

For excessively deep hierarchies:

Identify which levels represent true specialization vs. feature accumulation
Extract accumulated features into composed objects
Collapse intermediate levels that don't represent genuine classifications
Use interfaces for type relationships, composition for shared behavior

Refactoring Risk

Prior to Refactoring:

Add Tests: Ensure existing behavior is captured in tests
Identify Clients: Find all code that uses the hierarchy
Plan Increments: Break the refactoring into small, reversible steps
Communicate: Inform the team about the planned changes
Create Parallel Structure: Build the new design alongside the old before switching

Summary: Common Relationship Mistakes

We've catalogued the most common IS-A vs HAS-A mistakes, their causes, symptoms, and remedies. Let's consolidate:

Key Takeaways

•Inheritance for code reuse — Use composition instead; delegate to contained objects
•Inheritance for changeable roles — Model roles as composed objects that can be added/removed
•LSP violations — Rethink the hierarchy or use composition for varying capabilities
•Deep hierarchies — Flatten with composition; aim for ≤ 3 levels
•Abstract grab-bags — Inject dependencies explicitly; don't force shared utilities through inheritance
•Watch for symptoms — instanceof, UnsupportedOperationException, testing difficulty, type enums
•Refactor carefully — Add tests first, change incrementally, verify at each step

Module Complete:

You now have a complete understanding of IS-A vs HAS-A relationships:

IS-A (Page 1): Inheritance as type identity and substitutability
HAS-A (Page 2): Composition as containment and delegation
Testing (Page 3): A systematic framework for choosing the right relationship
Mistakes (Page 4): Common errors and how to avoid or fix them

With this knowledge, you can design class relationships that are semantically correct, flexible, and maintainable—avoiding the traps that plague many codebases.

Module Complete