Lecture overview:

• Total time: ~60 minutes
• Prerequisites: Students understand coupling and cohesion from L7
• Connects to: Assignment 2 (designing changeable systems)

Structure:

• SOLID principles overview (~20 min)
• Composition over inheritance (~10 min)
• Rules for safe inheritance (~5 min)
• Decorator pattern (~15 min)
• When to use inheritance (~10 min)

Key theme: Inheritance is powerful but risky. Learn when to use it, when to avoid it, and how to do it safely.

→ Transition: Let's start with the learning objectives...

CS 3100: Program Design and Implementation II

Lecture 8: Changeability III — Principles for Inheritance

©2025 Jonathan Bell & Ellen Spertus, CC-BY-SA

Context from L7:

• Students learned about coupling and cohesion
• They can now analyze code for changeability
• This lecture provides concrete design principles

Key theme: SOLID principles and composition patterns help us write code that's easier to change and extend.

→ Transition: Here's what you'll be able to do after today...

Poll: Have you read any Effective Java?

A. Never heard of it

B. Not yet

C. I've found it online

D. I've skimmed parts

E. I've read 1 or 2 items

F. I've read many items

Learning Objectives

After this lecture, you will be able to:

1. Apply the SOLID principles to evaluate and improve object-oriented designs
2. Explain why composition is generally preferred over inheritance and identify cases where each is appropriate
3. Describe rules for safely implementing inheritance in your own code
4. Define the Decorator pattern and explain its relationship to design for change

Time allocation:

• Objective 1: SOLID principles (~20 min)
• Objective 2: Composition over inheritance (~10 min)
• Objective 3: Safe inheritance rules (~5 min)
• Objective 4: Decorator pattern (~15 min)
• Plus cases for inheritance (~10 min)

Why this matters: These principles guide decisions you'll make on every software project.

→ Transition: Let's review what coupling and cohesion mean...

SOLID Principles Guide Decisions About Class Design

Historical context:

• Robert C. Martin ("Uncle Bob") wrote about these in 2000
• He didn't invent all of them—Bertrand Meyer (O) in 1988, Barbara Liskov (L) in 1987
• Michael Feathers coined "SOLID" in 2004

Key insight:

• These are guidelines, not laws
• Trade-offs always exist
• We'll look at each principle in context

→ Transition: Let's start with Single Responsibility...

Classes With Multiple Responsibilities Are Hard to Change

Single Responsibility Principle: "A class should have only one reason to change."

This is cohesion applied to classes. A class with a single responsibility is easier to understand, test, and modify.

// Violates SRP - five reasons to change!
public class SubmissionService {
    public void processSubmission(Submission submission) {
        TestResult testResult = runTests(submission);        // Testing logic
        LintResult lintResult = lintSubmission(submission);  // Linting logic
        GradingResult grade = gradeSubmission(submission, testResult, lintResult);  // Grading
        saveSubmission(submission, grade);                   // Persistence logic
        sendNotification(submission.student, grade);         // Notification logic
    }
}

SOLID: Single-Responsibility Principle

The problem:

• Five different responsibilities in one class
• Change to email format → modify SubmissionService
• Change to grading algorithm → modify SubmissionService
• Change to database schema → modify SubmissionService

This is low cohesion:

• Methods do unrelated things
• You must understand everything to change anything

→ Transition: How do we fix this?

Delegation Separates Concerns Into Focused Classes

public class SubmissionProcessor {
    private final TestRunner testRunner;
    private final Linter linter;
    private final Grader grader;
    private final SubmissionRepository repository;
    private final NotificationService notifier;

    public void processSubmission(Submission submission) {
        TestResult testResult = testRunner.run(submission);
        LintResult lintResult = linter.analyze(submission);
        GradingResult gradeResult = grader.grade(submission, testResult, lintResult);
        repository.save(submission, gradeResult);
        notifier.notify(submission.student, gradeResult);
    }
}

✓ Each class has one job. Changes to linting don't touch testing or grading code.

SOLID: Single-Responsibility Principle

Benefits:

• Each class has a single, focused responsibility
• SubmissionProcessor orchestrates but doesn't implement
• Changes to linting only affect Linter
• You don't need to look at other files

Connection to L7:

• This is functional cohesion at the class level
• Low coupling between the components

→ Transition: Next principle: Open/Closed...

Can you create a subtype without modifying existing code?

public interface IoTDevice {
  void identify();
  boolean isAvailable();
}

public class Light implements IoTDevice {
  // ... implementation ...
}

A. Yes, for both types

B. Only for IoTDevice

C. Only for Light

D. Not for either

SOLID: Open-Closed Principle

Good Modules Can Be Extended Without Being Modified

Open/Closed Principle: "Software entities should be open for extension but closed for modification."

SOLID: Open-Closed Principle

The goal:

• Add new behavior without touching existing code
• Existing code is tested and working—don't risk breaking it

How we achieve this:

• Design with abstraction and polymorphism
• New functionality = new classes implementing existing interfaces

→ Transition: Let's see an example...

Interfaces Enable Extension Without Modification

// Existing interface - OPEN for extension, CLOSED for modification
public interface IoTDevice {
    void identify();
    boolean isAvailable();
}

// Existing implementation - works, don't touch it
public class Light implements IoTDevice {
    // ... implementation ...
}

// OPEN for extension - add new device types freely!
public class SmartThermostat implements IoTDevice {
    @Override
    public void identify() { /* Flash display */ }

    @Override
    public boolean isAvailable() { return true; }

    // New behavior specific to thermostats
    public void setTemperature(int temp) { /* ... */ }
}

Adding SmartThermostat doesn't require changing IoTDevice or Light.

SOLID: Open-Closed Principle

Key insight:

• The interface defines the contract
• Anyone can implement it
• Existing code that uses IoTDevice automatically works with SmartThermostat

This is Strategy pattern territory:

• Different implementations behind a common interface
• We saw this in L7

→ Transition: The next principle ensures extensions behave correctly...

Poll: Which can be subtypes of Mammal?

A. Bird

B. Fish

C. Person

D. Plant

E. Cat

SOLID: Liskov Substitution Principle

Subclasses Must Be Substitutable for Their Parent Classes

Liskov Substitution Principle: Objects of a supertype should be replaceable with objects of its subtypes without breaking the application.

SOLID: Liskov Substitution Principle

We introduced this in Lecture 2:

• Behavioral subtyping
• Subtypes must honor the contract of the parent
• The supertype can be a class or an interface

Why it matters:

• Code written for the supertype should work with any subtype
• If a subclass breaks expectations, it breaks all calling code

→ Transition: Let's see good and bad examples...

Subclasses That Break Expectations Break All Calling Code

Good: LSP preserved

public class DimmableLight extends Light {
  private int brightness = 100;

  @Override
  public void turnOn() {
    // Honor contract by turning on light
    super.turnOn();
    // Can also add dimming capability
  }

  public void setBrightness(int b) {
    this.brightness = b;
  }
}

Bad: LSP violated

public class BrokenLight extends Light {
  @Override
  public void turnOn() {
    // Does not honor contract!
    throw new UnsupportedOperationException(
      "This light can't be turned on!");
  }
}

Code that calls light.turnOn() shouldn't need to check if it's a BrokenLight first.

SOLID: Liskov Substitution Principle

The test:

• Can you use the subclass anywhere the superclass is expected?
• Does it behave as expected?

Violations are subtle:

• Throwing unexpected exceptions
• Returning unexpected values
• Strengthening preconditions or weakening postconditions

→ Transition: Next up: Interface Segregation...

Poll: What type of interface(s) to prefer?

A: One large interface

public interface SmartDevice {
    void turnOn();
    void turnOff();
    void setBrightness(int level);
    void setColorTemperature(int temp);
    void setFanSpeed(int speed);
}

B: Many small interfaces

public interface Switchable {
    void turnOn();
    void turnOff();
}

public interface Dimmable {
    void setBrightness(int level);
}

public interface ColorAdjustable {
    void setColorTemperature(int temp);
}

SOLID: Interface Segregation Principle

Give students a moment to vote before revealing that B demonstrates the Interface Segregation Principle.

Discussion points:

• What if you have a simple fan that can only turn on/off?
• With A, you'd have to implement methods you don't need
• With B, just implement Switchable

Large Interfaces Force Clients to Depend on Methods They Don't Use

Interface Segregation Principle: "Clients should not be forced to depend on interfaces they don't use."

SOLID: Interface Segregation Principle

This is SRP for interfaces:

• Don't bundle unrelated capabilities
• Clients shouldn't depend on methods they don't use

Why it matters:

• Changes to unused methods still require recompilation
• Implementations must provide methods they don't need
• Interface becomes harder to understand

→ Transition: Let's see the code...

Smaller Interfaces Reduce Unnecessary Dependencies

// Bad: Monolithic interface
public interface SmartDevice {
    void turnOn();
    void turnOff();
    void setBrightness(int level);    // Not all devices have this!
    void setColorTemperature(int temp); // Or this!
    void setFanSpeed(int speed);       // Or this!
}

// Better: Segregated interfaces
public interface Switchable {
    void turnOn();
    void turnOff();
}

public interface Dimmable {
    void setBrightness(int level);
}

public interface ColorAdjustable {
    void setColorTemperature(int temp);
}

SOLID: Interface Segregation Principle

The improvement:

• Each interface has one focused purpose
• Devices implement only what they need

Java allows multiple interface implementation:

• class SmartBulb implements Switchable, Dimmable, ColorAdjustable
• class SimpleFan implements Switchable

→ Transition: Final SOLID principle...

Classes Should Implement Only the Interfaces They Need

// Simple fan - just needs on/off
public class SimpleFan implements Switchable {
    public void turnOn() { /* start motor */ }
    public void turnOff() { /* stop motor */ }
    // No need to implement dimming or color!
}

// Smart bulb - implements all capabilities
public class SmartBulb implements Switchable, Dimmable, ColorAdjustable {
    public void turnOn() { /* ... */ }
    public void turnOff() { /* ... */ }
    public void setBrightness(int level) { /* ... */ }
    public void setColorTemperature(int temp) { /* ... */ }
}

✓ Each class implements exactly the interfaces it needs—no more, no less.

SOLID: Interface Segregation Principle

Benefits:

• Clear what each device supports
• No dummy implementations throwing UnsupportedOperationException
• Easier to test—only test what the interface promises

→ Transition: Last principle: Dependency Inversion...

Poll: Which dependency is better?

A: Dependency on concrete type

public class UserRepository {
    private MySQL database;

    public UserRepository(MySQL database) {
        this.database = database;
    }
}

B: Dependency on abstract type

public class UserRepository {
    private Database database;

    public UserRepository(Database database) {
        this.database = database;
    }
}

SOLID: Dependency Inversion Principle

High-Level Modules Should Not Depend on Low-Level Details

Dependency Inversion Principle: "Depend on abstractions, not on concretions."

SOLID: Dependency Inversion Principle

The inversion:

• Instead of high-level depending on low-level...
• Both depend on an abstraction (interface)

Why "inversion"?

• Traditionally, high-level calls low-level directly
• We invert this by introducing an interface between them

→ Transition: Let's see code...

Abstractions Allow Implementations to Be Swapped

Bad: Direct dependency

public class PawtograderSystem {
    // Hardcoded to MySQL!
    private MySQLDatabase database =
        new MySQLDatabase();

    public void saveSubmission(
            Submission s) {
        database.save(s);
    }
}

Good: Depend on abstraction

public class PawtograderSystem {
    private final Database database;

    // Accepts any Database!
    public PawtograderSystem(
            Database database) {
        this.database = database;
    }

    public void saveSubmission(
            Submission s) {
        database.save(s);
    }
}

public interface Database {
    void save(Submission submission);
}

SOLID: Dependency Inversion Principle

Benefits:

• Can swap MySQL for PostgreSQL without changing PawtograderSystem
• Can use a mock Database for testing
• High-level policy separated from low-level details

This is constructor injection:

• The dependency is "injected" via the constructor
• Very common in modern Java frameworks

→ Transition: Let's summarize SOLID...

SOLID Principles Work Together to Enable Change

Principle	Key Idea	Benefit
Single Responsibility	One reason to change	High cohesion
Open/Closed	Extend, don't modify	Safe evolution
Liskov Substitution	Subtypes honor contracts	Reliable polymorphism
Interface Segregation	Small, focused interfaces	Minimal dependencies
Dependency Inversion	Depend on abstractions	Loose coupling

⚠ These are guidelines, not laws. Always consider trade-offs in your specific context.

Looking ahead:

• These same principles scale to entire systems
• In Lectures 19-20, we'll see how they inform software architecture

For now:

• Apply these when designing classes and interfaces
• Use them to evaluate existing designs
• They help identify potential problems early

→ Transition: Now let's talk about inheritance specifically...

Inheritance Creates Tight Coupling That Composition Avoids

Effective Java Item 18: "Favor composition over inheritance"

Why favor composition?

• Inheritance creates tight coupling
• Subclass depends on superclass implementation details
• Changes to superclass can break subclasses unexpectedly

Composition is more flexible:

• Objects are assembled from parts
• Parts can be swapped independently
• Each part has its own interface

→ Transition: Let's see a concrete example of the problem...

Subclasses Depend on Superclass Implementation Details

Imagine we want a Set that counts how many items are passed to add() and addAll():

public class InstrumentedHashSet<E> extends HashSet<E> {
    private int addCount = 0;

    @Override
    public boolean add(E e) {
        addCount++;
        return super.add(e); // return true if added
    }

    @Override
    public boolean addAll(Collection<? extends E> c) {
        addCount += c.size();
        return super.addAll(c);
    }

    public int getAddCount() { return addCount; }
}

What does getAddCount() return after s.addAll(Arrays.asList("A", "B", "C"))?

The trap:

• This looks reasonable at first glance
• We increment count in both add and addAll

Think about it:

• We add 3 elements with addAll
• What will getAddCount() return?

→ Transition: Let's find out...

Hidden Implementation Details Cause Unexpected Behavior

InstrumentedHashSet<String> s = new InstrumentedHashSet<>();
s.addAll(Arrays.asList("A", "B", "C"));
System.out.println(s.getAddCount()); // Prints 6, not 3!

What happened:

• HashSet.addAll() internally calls add() for each element
• Our add() increments the counter
• Our addAll() also increments the counter
• Double counting!

The fundamental problem:

• We depended on implementation details of HashSet
• Those details aren't part of the public contract
• HashSet could change this behavior in a future version

→ Transition: How do we fix this?

Composition Delegates Without Depending on Implementation

public class InstrumentedSet<E> implements Set<E> {
    private final Set<E> s;        // Composition: HAS-A Set
    private int addCount = 0;

    public InstrumentedSet(Set<E> s) {
        this.s = s;
    }

    @Override
    public boolean add(E e) {
        addCount++;
        return s.add(e);           // Delegate to wrapped set
    }

    @Override
    public boolean addAll(Collection<? extends E> c) {
        addCount += c.size();
        return s.addAll(c);        // Delegate - don't care how it's implemented!
    }

    public int getAddCount() { return addCount; }

    // Forward all other Set methods to s...
    @Override public int size() { return s.size(); }
    @Override public boolean isEmpty() { return s.isEmpty(); }
    // ... etc ...
}

Why this works:

• We don't extend HashSet—we wrap it
• We call s.addAll(), not super.addAll()
• We don't care if addAll calls add internally
• Our counting is independent of the wrapped set's implementation

Bonus flexibility:

• Can wrap ANY Set implementation
• new InstrumentedSet<>(new HashSet<>())
• new InstrumentedSet<>(new TreeSet<>())

→ Transition: Let's visualize the difference...

HashSet Class Hierarchy

Composition Keeps Method Calls Inside the Wrapped Object

Inheritance: count = 6 ❌

Composition: count = 3 ✓

The key insight:

• With inheritance, super.addAll() calls this.add(), which is our override
• With composition, s.addAll() calls its own add(), not ours

This respects encapsulation:

• We don't need to know how HashSet implements addAll
• We just use its public interface
• Changes to HashSet won't break us

→ Transition: When should we actually use inheritance?

Inheritance Requires Explicit Design and Documentation

Effective Java Item 19: "Design and document for inheritance or else prohibit it"

Two safe options:

1. Design explicitly for inheritance with thorough documentation
2. Prohibit inheritance entirely

There's no safe middle ground:

• Undocumented inheritance is asking for trouble
• The fragile base class problem is always lurking

→ Transition: Let's see what good documentation looks like...

Document Which Methods Call Which Other Methods

public abstract class AbstractSubmissionProcessor {
    /**
     * Processes a submission. This method calls {@link #validate(Submission)}
     * followed by {@link #grade(Submission)} if validation succeeds.
     */
    public final GradingResult process(Submission submission) {
        if (validate(submission)) {
            return grade(submission);
        }
        return GradingResult.invalid();
    }

    /**
     * Validates a submission. Subclasses must override this method
     * to provide language-specific validation.
     */
    protected abstract boolean validate(Submission submission);

    /**
     * Grades a submission. Subclasses must override this method
     * to provide language-specific grading.
     */
    protected abstract GradingResult grade(Submission submission);
}

Key practices:

1. Document which methods call which - process() calls validate() then grade()
2. Make template methods final - process() can't be overridden
3. Mark extension points clearly - protected abstract methods
4. Minimize protected members - each is a commitment

→ Transition: Or just prevent inheritance entirely...

Most Classes Should Be Final By Default

// Prevent inheritance by making the class final
public final class SubmissionValidator {
    // Cannot be extended - no surprises possible

    public boolean validate(Submission submission) {
        // Implementation details can change freely
        // No subclass depends on them
    }
}

Most classes should be either:

• Explicitly designed for inheritance with thorough documentation, OR
• Declared final to prevent inheritance entirely

When to use final:

• When you don't want to commit to supporting subclasses
• When you want freedom to change implementation details
• Most classes should be final by default

Java's standard library regrets:

• Many classes like HashSet aren't final
• Can't be changed now without breaking existing code

→ Transition: Now let's look at a pattern that uses composition brilliantly...

Design Patterns

Popularized in a 1994 book Design Patterns: Elements of Reusable Object-Oriented Software

Strategy: swap algorithms at runtime via a common interface

Decorator: wrap objects to dynamically add behavior

Template Method: enable subclasses to customize algorithm steps

Decorators Add Behavior Through Composition, Not Inheritance

A structural design pattern that adds behavior to objects dynamically using composition.

The pattern structure:

• Component: the interface everything implements
• ConcreteComponent: the base implementation
• Decorator: wraps a Component, IS-A Component
• ConcreteDecorators: add specific behaviors

Key insight:

• Decorators wrap components
• Each decorator adds one behavior
• You can stack decorators

→ Transition: You've already used this pattern...

Java InputStream

Java I/O Streams Stack Decorators for Flexible Combinations

Wrapping streams:

// Base: read bytes from file
InputStream file = new FileInputStream("data.txt");

// Decorator #1: add buffering
InputStream buf = new BufferedInputStream(file);

// Decorator #2: add primitive reading
DataInputStream data = new DataInputStream(buf);

int value = data.readInt();

Call delegation:

Why this design is powerful:

• FileInputStream: reads raw bytes from a file
• BufferedInputStream: adds buffering (performance)
• DataInputStream: adds methods to read primitive types

Each decorator:

• Implements InputStream
• Wraps another InputStream
• Adds one specific enhancement

→ Transition: Why is this better than inheritance?

A Visual Decorator Example

Source: Design Patterns (1994) by Gamma et al., chapter 4

Decorators Avoid the Class Explosion Problem

The class explosion problem:

• With inheritance, you need a class for every combination
• 3 sources × 3 enhancements = 9 classes minimum
• Adding a new enhancement? Multiply everything again!

With decorators:

• 3 source classes + 3 decorator classes = 6 classes
• Add any combination at runtime
• Adding a new enhancement? Just 1 new class

→ Transition: What are the benefits for changeability?

Decorators Support Good Design Principles

• Single Responsibility Principle: Each decorator does one thing
• Open/Closed Principle: Add new decorators without modifying existing code
• Avoid class explosion: Compose instead of creating subclasses for every combination

Example combinations without new classes:

// Buffered file reading
new BufferedInputStream(new FileInputStream("data.txt"))

// Buffered, compressed network reading
new BufferedInputStream(new GZIPInputStream(new URL(url).openStream()))

// Data reading from bytes in memory
new DataInputStream(new ByteArrayInputStream(bytes))

The flexibility:

• Any source can be wrapped with any decorator
• Decorators can wrap other decorators
• All combinations work automatically

This is composition over inheritance in action:

• Each decorator HAS-A stream (composition)
• Each decorator IS-A stream (interface)

→ Transition: Are there downsides?

Decorators Trade Explicitness for Flexibility

• More verbose: Lots of wrapper instantiation
• Harder to understand: Can't tell capabilities from type alone
• Runtime composition: Structure hidden until execution

The trade-off:

• Flexibility comes at the cost of explicitness
• Looking at InputStream stream, you don't know what it can do
• With inheritance, DataFileInputStream is clear in the type

When decorators hurt:

• When you need to know exact capabilities at compile time
• When the nesting gets very deep
• When most combinations are never used

→ Transition: So when should we use inheritance?

Inheritance Works Well for Specific Design Patterns

Three good uses for inheritance:

1. Template Method pattern - algorithmic skeleton
2. Natural type hierarchies - genuine IS-A relationships
3. Skeletal implementations - help implementing interfaces

Notice:

• All are carefully designed for inheritance
• All have clear documentation
• All have stable relationships

→ Transition: Let's look at Template Method...

Template Methods Define Algorithm Skeletons That Subclasses Complete

Define the algorithm skeleton in the base class; let subclasses fill in the details.

public abstract class AbstractTestRunner {
    // Template method - defines the algorithm structure
    public final TestResult runTests(Submission submission) {
        setUp();
        try {
            compileCode(submission);
            List<TestCase> tests = loadTestCases();
            TestResult result = new TestResult();
            for (TestCase test : tests) {
                beforeEach();
                result.add(executeTest(test, submission));
                afterEach();
            }
            return result;
        } finally {
            tearDown();
        }
    }

    // Hooks with defaults         // Abstract methods subclasses must implement
    protected void setUp() {}      protected abstract void compileCode(Submission s);
    protected void tearDown() {}   protected abstract List<TestCase> loadTestCases();
    protected void beforeEach() {} protected abstract TestOutcome executeTest(
    protected void afterEach() {}      TestCase test, Submission s);
}

The pattern:

• runTests() is the template method (final!)
• It defines the algorithm structure
• Subclasses implement the abstract methods
• Hooks (setUp, etc.) have default implementations

Why inheritance works here:

• Clear contract about what to override
• Template method is final—can't break the algorithm
• Subclasses focus on specific details

→ Transition: Another good case...

True "Is-A" Relationships Create Stable Hierarchies

public abstract class Shape {
    protected double x, y;  // Position

    public abstract double area();
    public abstract double perimeter();

    public void moveTo(double x, double y) {
        this.x = x;
        this.y = y;
    }
}

public class Circle extends Shape {
    private double radius;

    @Override
    public double area() {
        return Math.PI * radius * radius;
    }

    @Override
    public double perimeter() {
        return 2 * Math.PI * radius;
    }
}

✓ A Circle truly "is-a" Shape. The relationship is stable and meaningful.

When IS-A relationships work:

• Fundamental to the problem domain
• Stable—unlikely to change
• Semantically meaningful

The Shape hierarchy is classic:

• All shapes have position, area, perimeter
• Each shape computes these differently
• No confusion about the relationship

→ Transition: One more case: skeletal implementations...

Abstract Classes Can Provide Helpful Default Implementations

public interface Light {
    void turnOn();
    void turnOff();
    boolean isOn();
}

// Skeletal implementation - does the boring work
public abstract class AbstractLight implements Light {
    private boolean on = false;

    @Override
    public void turnOn() {
        if (!on) { on = true; activateHardware(); }
    }

    @Override
    public void turnOff() {
        if (on) { on = false; deactivateHardware(); }
    }

    @Override
    public boolean isOn() { return on; }

    // Subclasses implement hardware-specific behavior
    protected abstract void activateHardware();
    protected abstract void deactivateHardware();
}

The pattern:

• Interface defines the contract (Light)
• Abstract class provides common implementation (AbstractLight)
• Subclasses implement the hardware-specific parts

Java examples:

• AbstractList, AbstractSet, AbstractMap
• Implement most methods using a few core abstract methods

The flexibility:

• Extend AbstractLight if it fits
• Implement Light directly if it doesn't

→ Transition: Let's summarize when to use what...

When to Use Inheritance

1. There's a genuine "is-a" relationship fundamental to the domain
2. You control both base and subclasses (or trust the base class designer)
3. The base class is explicitly designed for inheritance with clear documentation
4. You're implementing a well-established pattern like Template Method
5. You need to share code between closely related classes

The key question:

• Is this truly an "is-a" relationship?
• Or am I just trying to reuse some code?

When to Avoid Inheritance

1. You're trying to reuse code but there's no natural "is-a" relationship
2. The base class wasn't designed for inheritance
3. You want to modify behavior of existing classes (use Decorator)
4. You want multiple inheritance of behavior (use interfaces with default methods)
5. The hierarchy would be deep (more than 2-3 levels is often a smell)

If just reusing code:

• Composition is almost always better
• Delegation gives the same code reuse without the coupling

→ Transition: Let's wrap up...

Key Takeaways

• SOLID principles provide guidelines for changeable OO design
• Favor composition over inheritance to avoid the fragile base class problem
• Design for inheritance or prohibit it — document self-use or use final
• Decorator pattern adds behavior through composition, not inheritance
• Use inheritance for template methods, natural hierarchies, and skeletal implementations

For your assignments:

• Consider SOLID when designing classes
• Prefer composition unless inheritance is clearly better
• Use interfaces to enable flexibility

Looking ahead:

• These same principles scale to entire systems
• Architecture lectures will revisit these ideas at a larger scale