Polymorphism

Compile-time polymorphism (static binding) resolves method calls at compile time. The compiler determines which method to call based on the method signature.

Method Overloading

public class MathUtils {
    // Same name, different parameters
    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;
    }
    
    public String add(String a, String b) {
        return a + b;
    }
}

// Compiler resolves at compile time
MathUtils math = new MathUtils();
math.add(1, 2);        // Calls int version
math.add(1.5, 2.5);    // Calls double version
math.add(1, 2, 3);     // Calls 3-param version
math.add("Hi", " There"); // Calls String version

Constructor Overloading

public class User {
    private String name;
    private String email;
    private int age;
    
    public User() {
        this.name = "Anonymous";
    }
    
    public User(String name) {
        this.name = name;
    }
    
    public User(String name, String email) {
        this.name = name;
        this.email = email;
    }
    
    public User(String name, String email, int age) {
        this.name = name;
        this.email = email;
        this.age = age;
    }
}

Operator Overloading (Some Languages)

# Python supports operator overloading
class Vector:
    def __init__(self, x, y):
        self.x = x
        self.y = y
    
    def __add__(self, other):  # Overload + operator
        return Vector(self.x + other.x, self.y + other.y)
    
    def __repr__(self):  # Overload string representation
        return f"Vector({self.x}, {self.y})"

Benefits of Compile-Time Polymorphism

1. Readability: Same operation name for different input types
2. Convenience: Multiple ways to call the same function
3. Performance: No runtime overhead (resolved at compile time)
4. Type Safety: Compiler ensures correct parameter types

Runtime polymorphism (dynamic binding) resolves method calls at runtime based on the actual object type, not the reference type.

Method Overriding

public interface PaymentProcessor {
    PaymentResult processPayment(Money amount);
}

public class CreditCardProcessor implements PaymentProcessor {
    @Override
    public PaymentResult processPayment(Money amount) {
        // Credit card logic
        return new PaymentResult(true, "CC-" + UUID.randomUUID());
    }
}

public class PayPalProcessor implements PaymentProcessor {
    @Override
    public PaymentResult processPayment(Money amount) {
        // PayPal logic
        return new PaymentResult(true, "PP-" + UUID.randomUUID());
    }
}

// Runtime polymorphism
PaymentProcessor processor = getProcessor(); // Could be either
processor.processPayment(amount); // Resolved at runtime

Polymorphic Collections

List<Shape> shapes = new ArrayList<>();
shapes.add(new Circle(5));
shapes.add(new Rectangle(4, 6));
shapes.add(new Triangle(3, 4, 5));

// Same method call, different behavior at runtime
for (Shape shape : shapes) {
    System.out.println("Area: " + shape.getArea()); // Polymorphic!
    System.out.println("Perimeter: " + shape.getPerimeter());
}

Dynamic Method Dispatch

Shape shape = new Circle(5);

shape.getArea()  // Runtime:
│
├── Reference type: Shape (compile-time check)
├── Object type: Circle (runtime type)
└── Method called: Circle.getArea() (dynamic dispatch)

Use Cases in System Design

1. Plugin Architecture:

public interface Plugin {
    void execute(Request request);
}

// Plugins loaded at runtime
List<Plugin> plugins = loadPlugins();
for (Plugin plugin : plugins) {
    plugin.execute(request); // Each plugin has different behavior
}

2. Strategy Pattern:

public interface SortStrategy {
    void sort(int[] array);
}

// Different sorting strategies
SortStrategy strategy = getUserChoice();
strategy.sort(array); // Runtime determines algorithm

3. Factory Pattern:

public class NotificationFactory {
    public static Notification create(NotificationType type) {
        return switch (type) {
            case EMAIL -> new EmailNotification();
            case SMS -> new SMSNotification();
            case PUSH -> new PushNotification();
        };
    }
}

Notification notification = NotificationFactory.create(type);
notification.send(message); // Polymorphic behavior

Polymorphism is everywhere in system design. Recognizing when to apply it is a key skill.

Polymorphism in Real Systems

┌─────────────────────────────────────────────────────┐
│                 Notification System                  │
├─────────────────────────────────────────────────────┤
│                                                     │
│  Notification (interface)                           │
│  ├── EmailNotification                             │
│  ├── SMSNotification                               │
│  ├── PushNotification                              │
│  └── SlackNotification                             │
│                                                     │
│  User preferences determine which to use            │
│  Same API: notification.send(message)               │
└─────────────────────────────────────────────────────┘

Pattern Applications

Pattern	Polymorphism Type	Use Case
Strategy	Runtime	Algorithm selection
Observer	Runtime	Event handling
Factory	Runtime	Object creation
Template Method	Runtime	Algorithm skeleton
Decorator	Runtime	Adding behavior
Adapter	Runtime	Interface conversion

Designing for Polymorphism

1. Program to Interface:

// Good: Depends on interface
List<PaymentProcessor> processors = List.of(
    new CreditCardProcessor(),
    new PayPalProcessor()
);

// Bad: Depends on concrete class
List<CreditCardProcessor> processors = ...;

2. Open-Closed Principle:

// Open for extension: add new DiscountStrategy implementations
// Closed for modification: no changes to existing code
public interface DiscountStrategy {
    Money calculateDiscount(Order order);
}

public class PercentageDiscount implements DiscountStrategy { }
public class FixedAmountDiscount implements DiscountStrategy { }
public class BuyOneGetOneFree implements DiscountStrategy { }

3. Dependency Injection:

public class OrderService {
    private final PaymentProcessor processor;
    
    // Injected: runtime polymorphism
    public OrderService(PaymentProcessor processor) {
        this.processor = processor;
    }
    
    public Order checkout(Cart cart) {
        return processor.processPayment(cart.getTotal());
    }
}

When to Use Polymorphism

Situation	Approach
Multiple implementations of same behavior	Runtime polymorphism
Algorithm selection at runtime	Strategy pattern
Same operation, different input types	Compile-time (overloading)
Plugin/extension architecture	Runtime polymorphism
Framework designed for extension	Runtime polymorphism

Common Anti-Patterns

1. Type checking with instanceof: Replace with polymorphism
2. Switch on type: Use strategy/factory instead
3. Downcasting: Indicates poor hierarchy design
4. Leaking concrete types: Always return interfaces