Polymorphism OOP Fundamentals – Dynamic Binding, Overriding, Overloading, Generics

This article is a glossary entry on polymorphism in OOP – including exam questions and tags.

In a Nutshell

Polymorphism enables a single call to be applied to different concrete implementations, with the selection of the appropriate method occurring context-dependently, usually at runtime. The result is flexible, extensible software with reduced coupling to concrete types.

Compact Technical Description

Polymorphism refers to the ability of objects to respond differently to the same message, depending on their actual type. The core is dynamic binding – method calls are resolved at runtime via dispatch tables, vtable, to the appropriate implementation. We distinguish subtype polymorphism via interfaces and inheritance, parametric polymorphism via generics, and ad hoc polymorphism via overloading. Polymorphic design supports the Open Closed Principle; extensions occur through new types rather than modifying existing ones.

Exam-Relevant Key Points

• Subtype polymorphism, use via base type or interface, concrete implementation is bound at runtime
• Parametric polymorphism, generics, one algorithm for many types, type-safe without casting
• Ad hoc polymorphism, overloading, same name, different parameters, binding is static
• IHK relevant, explain the difference between overriding vs. overloading precisely, dynamic vs. static binding
• Practice, strategy pattern uses polymorphism for behavior exchangeability without if-else chains
• Security aspect, contracts and invariants protect against faulty substitution, validate inputs
• Economics, reduces maintenance costs through extensibility, fewer conditional branches
• Documentation obligation, interface contracts, preconditions, postconditions, side effects described clearly

Core Components

1. Contract interface, method signatures and semantics
2. Implementations, concrete classes, strategies
3. Dynamic dispatch, vtable, single dispatch
4. Static dispatch, compile-time resolution in overloading
5. Generics, type parameters, constraints
6. Testability, contract and substitution tests
7. Design patterns, strategy, template method, visitor
8. Error handling, exceptions compatible with base interface
9. Performance aspects, indirect calls, inlining, JIT optimization
10. Tool support, UML, class diagrams, sequence diagrams

Practical Example

// Subtype polymorphism via strategy
interface PaymentMethod {
Receipt pay(int cents)
}

class CreditCard implements PaymentMethod {
public Receipt pay(int cents) {
// Authorization, clearing
return new Receipt("credit card", cents)
}
}

class PayPal implements PaymentMethod {
public Receipt pay(int cents) {
// Token, capture
return new Receipt("paypal", cents)
}
}

class CheckoutService {
private PaymentMethod method
public CheckoutService(PaymentMethod method) { this.method = method }
public Receipt checkout(int cents) {
if (cents <= 0) throw new IllegalArgumentException("positive amount required")
return method.pay(cents)
}
}

Explanation: CheckoutService communicates only with the PaymentMethod interface; concrete implementations are used interchangeably.

Advantages and Disadvantages

Advantages

• Clear separation of contract and implementation
• Better extensibility, reduced conditional logic
• Higher testability through mocks and stubs
• Promotes reusability and encapsulation

Disadvantages

• Indirect calls complicate debugging and performance analysis
• Incorrect or vague contracts lead to substitution errors
• Overly complex hierarchies increase cognitive load

Typical Exam Questions (with Brief Answer)

1. Polymorphism in the OOP context? The ability for different objects to be addressed through the same contract and execute type-dependent implementations at runtime.

2. Overloading vs. Overriding? Overloading, same method, different parameters, static binding. Overriding, inherited method is re-implemented with the same signature, dynamic binding.

3. Supports Open Closed Principle? New variants are added as new implementations of an existing interface; existing code remains unchanged.

4. Liskov Substitution Principle requires? Subclasses and implementations must honor the promises of the base type; do not tighten preconditions, do not weaken postconditions, preserve invariants.

5. Practical example without if-else cascade? Payment methods as strategies behind PaymentMethod, selection occurs through the concrete implementation, not through case distinctions.

6. Types of polymorphism? Subtype polymorphism, parametrized polymorphism via generics, ad hoc polymorphism via overloading, rarely multiple dispatch, visitor.

7. Test polymorphism effectively? Define contract test suite against the interface and run it against all implementations; additionally, mock-based interaction tests.

8. Duck typing and limitations? Behavior is considered valid if the required methods are present; no explicit type relationship needed, flexible, but less compile-time safety.

Most Important Sources

1. https://docs.oracle.com/javase/tutorial/java/IandI/polymorphism.html
2. https://de.wikipedia.org/wiki/Polymorphie_(Programmierung)
3. https://martinfowler.com/bliki/Polymorphism.html