Inheritance

Inheritance models the IS-A relationship where a subclass is a specialized version of its superclass.

The IS-A Test

Ask: "Is [subclass] a [superclass]?"

• Dog IS-A Animal ✓
• SavingsAccount IS-A BankAccount ✓
• Circle IS-A Shape ✓
• Car IS-A Engine ✗ (Car HAS-A Engine)

Inheritance Hierarchy

              ┌─────────┐
              │ Animal  │
              └────┬────┘
          ┌────────┴────────┐
    ┌─────┴─────┐    ┌─────┴─────┐
    │   Dog     │    │   Cat     │
    └─────┬─────┘    └───────────┘
          │
    ┌─────┴─────┐
    │  Puppy    │
    └───────────┘

public class Animal {
    protected String name;
    protected int age;
    
    public void eat() {
        System.out.println(name + " is eating");
    }
    
    public void sleep() {
        System.out.println(name + " is sleeping");
    }
}

public class Dog extends Animal {
    private String breed;
    
    public void bark() {
        System.out.println(name + " is barking");
    }
}

public class Puppy extends Dog {
    public void play() {
        System.out.println(name + " is playing");
    }
}

Liskov Substitution Principle (LSP)

Subclasses must be substitutable for their base class without altering correctness:

// Good: LSP satisfied
public class Bird {
    public void fly() { ... }
}

public class Sparrow extends Bird {
    // Sparrow can fly - LSP satisfied
}

// Bad: LSP violated
public class Ostrich extends Bird {
    @Override
    public void fly() {
        throw new UnsupportedOperationException(); // LSP violation!
    }
}

Common Inheritance Hierarchies

Domain Models:

PaymentMethod
├── CreditCard
├── DebitCard
├── PayPal
└── BankTransfer

Exception Hierarchies:

Exception
├── IOException
│   ├── FileNotFoundException
│   └── SocketException
├── SQLException
│   ├── ConnectionException
│   └── QueryException
└── IllegalArgumentException

When NOT to Use Inheritance

• When relationship is HAS-A, not IS-A
• When subclass needs fundamentally different behavior
• When hierarchy becomes too deep (3+ levels is a warning)
• When you find yourself overriding most methods

Overriding and overloading are often confused. They are fundamentally different mechanisms with different purposes.

Method Overriding

Same method signature in subclass, replacing parent behavior:

public class Animal {
    public void speak() {
        System.out.println("Some generic sound");
    }
}

public class Dog extends Animal {
    @Override  // Annotation: signals intent to override
    public void speak() {
        System.out.println("Woof!");
    }
}

// Runtime polymorphism
Animal animal = new Dog();
animal.speak();  // Output: Woof! (not "Some generic sound")

Method Overloading

Same method name, different parameter lists (within the same class):

class Calculator {
    public int add(int a, int b) {
        return a + b;
    }
    
    public double add(double a, double b) {
        return a + b;
    }
    
    public int add(int a, int b, int c) {
        return a + b + c;
    }
}

// Compile-time polymorphism
Calculator calc = new Calculator();
calc.add(1, 2);       // Calls int version
calc.add(1.5, 2.5);   // Calls double version
calc.add(1, 2, 3);    // Calls 3-param version

Key Differences

Aspect	Overriding	Overloading
Where	Subclass	Same class (or parent)
Signature	Must match	Must differ
Binding	Runtime (dynamic)	Compile-time (static)
Purpose	Specialize behavior	Same operation, different inputs
@Override	Recommended	Not applicable
Return type	Must be same/subtype	Can differ
Access	Cannot be more restrictive	Can differ

Overriding Rules

public class Parent {
    protected void display() { }
}

public class Child extends Parent {
    // ✓ Can increase visibility
    @Override
    public void display() { }
    
    // ✗ Cannot decrease visibility
    // @Override
    // private void display() { }  // Compile error!
    
    // ✗ Cannot change return type (except covariant)
    // @Override
    // int display() { }  // Compile error!
    
    // ✓ Can return subtype (covariant return)
    @Override
    public Object clone() { return new Child(); }
}

Common Mistakes

1. Forgetting @Override: Typos create new methods instead of overriding
2. Overloading when overriding intended: Different signature = new method
3. Changing semantics: Overriding should maintain the contract
4. Calling parent method: Forget super.method() when you need parent behavior

Composition over inheritance is a fundamental design principle: prefer containing objects over extending them.

The Problem with Deep Inheritance

         ┌─────────┐
         │ Vehicle │
         └────┬────┘
     ┌────────┴────────┐
┌────┴────┐      ┌─────┴────┐
│ Car     │      │ Truck    │
└────┬────┘      └──────────┘
     │
┌────┴──────────┐
│ SportsCar     │
└───────────────┘

Problems:
- Explosion of classes
- Tight coupling to parent
- Changes in parent affect all children
- Diamond problem in multiple inheritance

Composition Solution

// Instead of inheritance, compose behaviors
public class Vehicle {
    private Engine engine;
    private Transmission transmission;
    private GpsNavigator gps;
    
    public Vehicle(Engine engine, Transmission transmission, GpsNavigator gps) {
        this.engine = engine;
        this.transmission = transmission;
        this.gps = gps;
    }
    
    public void start() {
        engine.start();
        transmission.engage();
    }
}

// Flexible combinations
Vehicle sportsCar = new Vehicle(
    new V8Engine(),
    new ManualTransmission(),
    new PremiumGps()
);

Vehicle electricCar = new Vehicle(
    new ElectricEngine(),
    new NoTransmission(),
    new BasicGps()
);

HAS-A vs IS-A

IS-A (Inheritance)          HAS-A (Composition)
─────────────────          ──────────────────
Dog IS-A Animal             Car HAS-A Engine
Savings IS-A Account        Order HAS-A PaymentMethod
Square IS-A Shape           Server HAS-A Logger

Use when:                  Use when:
- Subtype relationship     - Assembling behaviors
- Subclass IS the parent   - Multiple capabilities
- Hierarchy is shallow     - Flexibility needed

Benefits of Composition

Benefit	Explanation
Flexibility	Change behavior at runtime
Testability	Easy to mock dependencies
Loose coupling	Components independent
Reuse	Behaviors shared across unrelated classes
No hierarchy explosion	Flat structure

Strategy Pattern with Composition

// Define behavior as interface
public interface SortStrategy {
    void sort(int[] array);
}

public class QuickSort implements SortStrategy {
    public void sort(int[] array) { /* quicksort */ }
}

public class MergeSort implements SortStrategy {
    public void sort(int[] array) { /* mergesort */ }
}

// Compose the behavior
public class Sorter {
    private SortStrategy strategy;
    
    public Sorter(SortStrategy strategy) {
        this.strategy = strategy;
    }
    
    public void sort(int[] array) {
        strategy.sort(array);
    }
    
    // Change behavior at runtime!
    public void setStrategy(SortStrategy strategy) {
        this.strategy = strategy;
    }
}

When to Use Inheritance

Despite composition being preferred, inheritance is still valid for:

• Clear IS-A relationships
• Framework requirements (extending framework classes)
• Template Method pattern
• Shallow hierarchies (1-2 levels)