Java Polymorphism Pitfall: Constructor Override Yields NPE

Polymorphism in Java is a powerful feature, but it comes with a hidden trap: calling overridable methods from constructors can cause NullPointerExceptions when subclass fields aren't initialized yet. This article breaks down the different types of polymorphism—runtime, compile-time, coercion, and operator overloading—and shows you exactly where the danger lies. Understanding these distinctions is essential for writing robust, production-grade Java code that avoids subtle bugs.

Polymorphism in Java: The Dynamic Dispatch You Can't Ignore

Polymorphism is the ability of an object to take many forms, but in Java it's specifically the mechanism where a reference variable of a superclass can point to an object of a subclass, and the correct overridden method is called at runtime based on the actual object type, not the reference type. This is dynamic method dispatch, powered by the virtual method table (vtable) in the JVM. Without it, you'd be stuck with static binding and compile-time decisions, losing the flexibility that makes OOP powerful.

At runtime, the JVM looks up the method in the object's actual class hierarchy, starting from the most specific subclass. This lookup is O(1) with a well-optimized vtable, but it's not free — each polymorphic call incurs a small indirection cost. The key property is that method overriding is resolved dynamically, while method overloading is resolved statically at compile time. This distinction is critical: you can't override static methods, private methods, or final methods — they are bound early, avoiding polymorphism entirely.

Use polymorphism when you have a family of related behaviors that differ by subtype, such as a payment processor handling credit cards, PayPal, and crypto. It lets you write code against an interface or abstract class, then swap implementations without changing callers. In real systems, this enables plugin architectures, strategy patterns, and clean separation of concerns. Without it, you'd litter code with instanceof checks and switch statements, making maintenance a nightmare.

Compile-Time Polymorphism — Method Overloading and Why It Exists

Compile-time polymorphism (also called static polymorphism) is resolved by the compiler before your program even runs. The compiler looks at the number and types of arguments you pass to a method and decides which version to call. This is method overloading.

Why does it exist? Because you often want the same logical operation — say, formatting a price — to accept different input types without forcing the caller to do awkward type conversions first. Overloading makes your API feel natural. Instead of formatPriceFromInt and formatPriceFromDouble, you just write formatPrice and the compiler routes the call correctly.

The key thing to internalise is that overloading is resolved at compile time based on the declared (reference) type, not the actual runtime type. That distinction becomes critical when you move to runtime polymorphism. Here the compiler picks the method — it's essentially a convenience feature for API ergonomics, not a design tool for extensibility. Use it when the same operation genuinely makes sense across multiple input types, not just to save yourself from writing slightly longer method names.

package io.thecodeforge;

public class InvoiceFormatter {

    // Overload 1: caller has a whole-number amount (e.g. loyalty points)
    public String formatPrice(int amountInCents) {
        double dollars = amountInCents / 100.0;
        // Format the integer input as a dollar string
        return String.format("$%.2f", dollars);
    }

    // Overload 2: caller already has a decimal amount
    public String formatPrice(double amount) {
        // Directly format the double — no conversion needed
        return String.format("$%.2f", amount);
    }

    // Overload 3: caller also wants a currency code (e.g. for international invoices)
    public String formatPrice(double amount, String currencyCode) {
        // The compiler picks THIS version when two arguments are passed
        return String.format("%s %.2f", currencyCode, amount);
    }

    public static void main(String[] args) {
        InvoiceFormatter formatter = new InvoiceFormatter();

        // Compiler resolves each call at compile time based on argument types
        System.out.println(formatter.formatPrice(1999));           // int version
        System.out.println(formatter.formatPrice(19.99));          // double version
        System.out.println(formatter.formatPrice(19.99, "EUR"));   // double + String version
    }
}

Coercion Polymorphism — Implicit Type Conversion in Java

Coercion polymorphism, also known as implicit type conversion, is a form of compile-time polymorphism where Java automatically converts one type to another when needed. This happens primarily in two contexts: numeric widening (e.g., int to long to float to double) and string concatenation using +.

Java’s type system permits implicit widening conversions without any explicit cast. When you call a method that expects a double but pass an int, the compiler automatically widens the parameter. This is coercion — the method hasn't changed its signature; the argument is implicitly converted. This is not overloading; it's a separate mechanism that enables polymorphism by letting different argument types satisfy the same method signature.

The most common and powerful coercion in Java is string concatenation. When you write "The value is " + 42, Java automatically converts the integer 42 into a string. This is not operator overloading in the C++ sense; it's a built-in language feature where the + operator is overloaded by the compiler specifically for string concatenation. If at least one operand is a String, the other is coerced to a String via String.valueOf().

Coercion is a silent convenience, but it can backfire. Precision loss can occur when widening from int to float (e.g., large int values lose precision) and when mixing numeric types in expressions. Always be explicit in critical calculations rather than relying on coercion.

package io.thecodeforge;

public class CoercionExample {

    // Demonstrates coercion numeric widening
    public static double computeTotal(double price, int quantity, double taxRate) {
        // The 'int' quantity is coerced to double
        return price * quantity * (1 + taxRate);
    }

    // Overloaded methods that rely on coercion
    public static String describe(Object obj) {
        return "Object: " + obj;
    }

    public static String describe(String str) {
        return "String: " + str;
    }

    public static void main(String[] args) {
        // Coercion: int literals are widened to double
        double total = computeTotal(19.99, 2, 0.08);
        System.out.println(total); // outputs 43.1784

        // Coercion: integer coerced to string via concatenation
        String message = "Order #" + 1001;
        System.out.println(message);

        // Coercion can cause ambiguity with overloading, but here it's fine
        System.out.println(describe(42));        // calls describe(Object) because int is boxed to Integer
        System.out.println(describe("hello"));   // calls describe(String)
    }
}

Operator Overloading in Java — The Language's Choice and Workarounds

Java does not support user-defined operator overloading like C++ or Python. The only operator that is overloaded by the language itself is +: it performs numeric addition when both operands are numeric types and string concatenation when one operand is a String. All other operators (-, *, /, ==, etc.) have a fixed meaning for primitive types and cannot be redefined for reference types.

This design choice was intentional. The Java language designers felt that operator overloading reduces readability and makes code harder to maintain. Instead, Java encourages using methods with descriptive names. For example, BigDecimal.add() instead of BigDecimal + BigDecimal. This avoids surprises when the + operator is used on objects.

However, the lack of operator overloading can lead to verbose code when dealing with mathematical objects like matrices or complex numbers. Libraries like Apache Commons Math or JScience provide classes with add() and multiply() methods, but you cannot write matrixA + matrixB. The JVM also uses the + operator for the invokedynamic instruction behind the scenes for string concatenation (since Java 9 uses StringConcatFactory), but that's an implementation detail.

For domain-specific types, you can implement fluent APIs or use method chaining to mimic the expressiveness of operator overloading. The key takeaway: Java's intentional omission of operator overloading pushes you toward clearer, more explicit code. If you find yourself desperately wanting + for your custom class, consider whether a well-named method like combine() or addTo() would be even clearer.

Polymorphism Types Comparison — Compile-Time vs Runtime at a Glance

Here is a quick visual comparison of the two main types of polymorphism in Java: compile-time (static) and runtime (dynamic). Understanding their differences is essential for writing flexible, correct Java code.

This table should help you quickly decide which type of polymorphism to use and what to watch out for. Remember, overloading is a convenience for callers; overriding is a design tool for extensibility.

Runtime Polymorphism — Method Overriding, the JVM, and the Magic of Dynamic Dispatch

Runtime polymorphism is where Java's real power lives. The JVM — not the compiler — decides which method to call based on the actual type of the object at runtime. This mechanism is called dynamic dispatch, and it's the engine behind almost every extensible framework ever written in Java.

You set it up with inheritance (or interface implementation) and method overriding: a subclass provides its own version of a method declared in a parent class or interface. The critical rule is that the reference type can be the parent, but the object itself is the child. When you call the overridden method, Java always runs the child's version.

This is the feature that makes it possible to write a method like processPayment(PaymentMethod method) once and have it correctly handle a CreditCard, a PayPal account, or a CryptoPay instance without any changes. You're programming to the PaymentMethod abstraction. Adding a new payment type tomorrow means writing a new class — you never touch the method that processes payments. That's the Open/Closed Principle in action, made possible entirely by runtime polymorphism.

package io.thecodeforge;

// Abstract base class — defines the contract every payment method must fulfil
abstract class PaymentMethod {
    protected String accountId;

    public PaymentMethod(String accountId) {
        this.accountId = accountId;
    }

    // Every subclass MUST provide its own version of this method
    public abstract String processPayment(double amount);

    // This method is shared — subclasses inherit it unchanged
    public String getAccountSummary() {
        return "Account: " + accountId;
    }
}

// Concrete subclass 1
class CreditCard extends PaymentMethod {
    private String lastFourDigits;

    public CreditCard(String accountId, String lastFourDigits) {
        super(accountId);
        this.lastFourDigits = lastFourDigits;
    }

    @Override
    public String processPayment(double amount) {
        // This version charges a card and adds a processing fee
        double fee = amount * 0.015;
        return String.format("Credit card ****%s charged $%.2f (fee: $%.2f)",
                lastFourDigits, amount, fee);
    }
}

// Concrete subclass 2
class PayPalAccount extends PaymentMethod {

    public PayPalAccount(String email) {
        super(email);
    }

    @Override
    public String processPayment(double amount) {
        // PayPal has a flat fee model — completely different logic, same method name
        return String.format("PayPal account %s debited $%.2f (flat fee: $0.30)",
                accountId, amount);
    }
}

// Concrete subclass 3 — added later, zero changes to PaymentProcessor needed
class CryptoPay extends PaymentMethod {

    public CryptoPay(String walletAddress) {
        super(walletAddress);
    }

    @Override
    public String processPayment(double amount) {
        // Crypto converts to BTC at a fake rate for illustration
        double btcAmount = amount / 45000.0;
        return String.format("Wallet %s sent %.6f BTC ($%.2f)",
                accountId, btcAmount, amount);
    }
}

public class PaymentProcessor {

    // This method was written ONCE. It works for every PaymentMethod — past and future.
    // The JVM uses dynamic dispatch to call the right processPayment() at runtime.
    public static void checkout(PaymentMethod method, double orderTotal) {
        System.out.println(method.processPayment(orderTotal)); // runtime decision
        System.out.println(method.getAccountSummary());        // shared inherited method
        System.out.println("---");
    }

    public static void main(String[] args) {
        // Reference type is PaymentMethod; actual object type varies — that's the point
        PaymentMethod card   = new CreditCard("ACC-001", "4242");
        PaymentMethod paypal = new PayPalAccount("user@example.com");
        PaymentMethod crypto = new CryptoPay("0xABCD1234");

        // Same method call, three completely different behaviours — runtime polymorphism
        checkout(card,   99.99);
        checkout(paypal, 99.99);
        checkout(crypto, 99.99);
    }
}

Interfaces vs Abstract Classes for Polymorphism — Choosing the Right Tool

Both interfaces and abstract classes let you write polymorphic code, but they serve different purposes and picking the wrong one creates awkward designs that are painful to refactor later.

Use an abstract class when your subclasses genuinely share implementation — common fields, shared helper methods, a partial template. The PaymentMethod class above is a reasonable abstract class because every payment method has an accountId and a shared getAccountSummary() method. The 'is-a' relationship is tight: a CreditCard really is a PaymentMethod.

Use an interface when you're defining a capability or role that unrelated classes might play. A Printable interface makes sense on a Document, an Invoice, and an Image even though those three share no common ancestor. Interfaces also let a class participate in multiple polymorphic hierarchies simultaneously (a class can implement many interfaces but only extend one class).

The modern Java best practice, since Java 8, is to favour interfaces with default methods for most polymorphic contracts. Reserve abstract classes for situations where shared mutable state or a constructor template is genuinely needed. When in doubt, start with an interface — it's far easier to widen an interface into an abstract class later than to break apart an inheritance hierarchy.

package io.thecodeforge;

// Interface defines a CAPABILITY — any class can implement this regardless of its lineage
interface Exportable {
    // Every implementor must know how to export itself
    byte[] exportData();

    // Default method: shared behaviour that implementors can optionally override
    default String getExportStatus() {
        return "Export ready: " + this.getClass().getSimpleName();
    }
}

// A completely unrelated second interface — Java allows implementing both
interface Auditable {
    String getAuditLog();
}

// SalesReport implements BOTH interfaces — impossible with single-inheritance abstract classes
class SalesReport implements Exportable, Auditable {
    private String reportName;
    private double totalRevenue;

    public SalesReport(String reportName, double totalRevenue) {
        this.reportName = reportName;
        this.totalRevenue = totalRevenue;
    }

    @Override
    public byte[] exportData() {
        // Simulate generating CSV bytes from the report data
        String csv = "Report,Revenue\n" + reportName + "," + totalRevenue;
        return csv.getBytes();
    }

    @Override
    public String getAuditLog() {
        return "SalesReport '" + reportName + "' exported at " + System.currentTimeMillis();
    }
}

class InventorySnapshot implements Exportable {
    private int itemCount;

    public InventorySnapshot(int itemCount) {
        this.itemCount = itemCount;
    }

    @Override
    public byte[] exportData() {
        // Simulate generating JSON bytes
        String json = "{\"itemCount\": " + itemCount + "}";
        return json.getBytes();
    }

    // Not overriding getExportStatus() — the default implementation is used instead
}

public class ReportExporter {

    // This method only cares that the object is Exportable — it doesn't know or care what type
    public static void runExport(Exportable exportable) {
        byte[] data = exportable.exportData();              // runtime polymorphism here
        System.out.println(exportable.getExportStatus());  // default or overridden version
        System.out.println("Bytes exported: " + data.length);
        System.out.println("---");
    }

    public static void main(String[] args) {
        SalesReport salesReport       = new SalesReport("Q4-2024", 128500.00);
        InventorySnapshot snapshot    = new InventorySnapshot(342);

        runExport(salesReport);   // Uses SalesReport's exportData()
        runExport(snapshot);      // Uses InventorySnapshot's exportData()

        // SalesReport also satisfies Auditable — dual polymorphic identity
        Auditable auditTarget = salesReport;
        System.out.println(auditTarget.getAuditLog());
    }
}

Covariant Return Types and the @Override Annotation — The Details That Matter

Two practical details of method overriding trip up a lot of intermediate developers: covariant return types and the @Override annotation.

Covariant return types mean an overriding method can return a more specific (sub)type than the parent method declares. If the parent says PaymentMethod createPaymentMethod(), a subclass can override it to return CreditCard createPaymentMethod(). The caller holding a PaymentMethod reference still works fine; a caller who knows they're dealing with the subclass can use the result directly as a CreditCard without casting. This is clean, type-safe, and reduces ugly casts throughout your codebase.

@Override looks optional because Java won't error without it — but always use it. It tells the compiler 'I intend to override a parent method here'. If you spell the method name wrong, or the parent method's signature changes, the compiler catches it immediately with a clear error. Without @Override you silently create a brand-new method instead of overriding, and your polymorphic behaviour simply doesn't fire. That's one of the most maddeningly subtle bugs in Java development.

package io.thecodeforge;

// Base factory class with a general return type
class VehicleFactory {

    // Returns the broad type Vehicle
    public Vehicle createVehicle(String model) {
        return new Vehicle(model, "generic");
    }
}

// Subclass uses a COVARIANT return type — returns ElectricCar instead of Vehicle
class ElectricCarFactory extends VehicleFactory {

    @Override // Compiler will error here if createVehicle doesn't exist in parent — safety net
    public ElectricCar createVehicle(String model) {
        // Covariant: ElectricCar IS-A Vehicle, so this is a valid override
        return new ElectricCar(model, "electric", 350);
    }
}

class Vehicle {
    protected String model;
    protected String fuelType;

    public Vehicle(String model, String fuelType) {
        this.model    = model;
        this.fuelType = fuelType;
    }

    public String describe() {
        return model + " (" + fuelType + ")";
    }
}

class ElectricCar extends Vehicle {
    private int rangeKm;

    public ElectricCar(String model, String fuelType, int rangeKm) {
        super(model, fuelType);
        this.rangeKm = rangeKm;
    }

    @Override
    public String describe() {
        // Overridden to include range — runtime polymorphism fires here
        return super.describe() + ", range: " + rangeKm + "km";
    }
}

public class VehicleFactoryDemo {
    public static void main(String[] args) {
        VehicleFactory genericFactory  = new VehicleFactory();
        ElectricCarFactory evFactory   = new ElectricCarFactory();

        // Covariant return: no cast needed when using the concrete factory type
        ElectricCar tesla = evFactory.createVehicle("Model S");
        System.out.println(tesla.describe());        // ElectricCar's describe() runs
        System.out.println("Range: " + tesla.rangeKm + "km");  // can access rangeKm directly

        // Polymorphism via parent reference: describe() still calls ElectricCar's version
        VehicleFactory upcastFactory = evFactory;    // reference is VehicleFactory type
        Vehicle vehicle = upcastFactory.createVehicle("Model 3"); // returns ElectricCar object
        System.out.println(vehicle.describe());      // runtime dispatch — ElectricCar.describe()
    }
}

The Liskov Substitution Principle — Why Polymorphism Requires Contracts

Polymorphism isn't free. The Liskov Substitution Principle (LSP) is the rule that makes it work safely: if you have a parent reference pointing to a child object, the child must not break the expectations that the parent's contract defines. That means: override methods must accept all arguments the parent accepts (and may accept even narrower ones), and must not throw new checked exceptions the parent didn't declare. In practice, violating LSP leads to code that randomly throws ClassCastException or unexpected UnsupportedOperationException.

A classic violation: a Square subclass of Rectangle where setting width also modifies height. Code that sets rectangle width and expects only width to change will break when passed a Square. The Square violates the parent's contract. To fix, don't model Square as a subclass of Rectangle — use composition or a separate hierarchy.

In your own code, always ask: 'Does this subclass honour the parent's contract? Would code written against the parent work with this subclass without knowing about it?' If the answer is no, you've broken LSP and your polymorphic dispatch will cause subtle bugs.

package io.thecodeforge;

// Violation: Square extends Rectangle, but setWidth also changes height
class Rectangle {
    protected int width;
    protected int height;

    public void setWidth(int w) { this.width = w; }
    public void setHeight(int h) { this.height = h; }
    public int getArea() { return width * height; }
}

class Square extends Rectangle {
    @Override
    public void setWidth(int w) {
        super.setWidth(w);
        super.setHeight(w);  // Violates LSP — caller expects only width to change
    }

    @Override
    public void setHeight(int h) {
        super.setHeight(h);
        super.setWidth(h);   // Same violation
    }
}

public class LSPExample {
    // This method works fine with Rectangle but breaks with Square
    public static void resizeAndPrint(Rectangle r) {
        int originalHeight = r.getHeight();  // Let's assume getter exists
        r.setWidth(10);
        // If r is a Square, setWidth also changes height — unexpected!
        System.out.println("Area: " + r.getArea() + " Expected: " + (10 * originalHeight));
    }

    public static void main(String[] args) {
        Rectangle rect = new Rectangle();
        rect.setWidth(5); rect.setHeight(8);
        resizeAndPrint(rect); // works: area = 10*8 = 80

        Rectangle sq = new Square();
        sq.setWidth(5); // height also becomes 5 (violation)
        resizeAndPrint(sq); // might produce wrong area
    }
}

instanceof Pattern Matching (Java 16+) — Safer Polymorphism with Type Checks

Introduced as a preview in Java 14 and standardised in Java 16, pattern matching for instanceof eliminates the tedious cast-and-check pattern that used to plague polymorphic code. Instead of writing:

``java if (obj instanceof String) { String s = (String) obj; // use s } ``

You now write:

``java if (obj instanceof String s) { // use s directly } ``

The variable s is declared and scoped only inside the if block, and it is automatically cast. This improves readability and eliminates the risk of forgetting to cast or casting to the wrong type.

Pattern matching is especially useful when you need polymorphic behaviour that cannot be expressed purely through overriding — for example, when handling objects from an external library whose classes you cannot modify. It also works with sealed classes and records, giving you exhaustive pattern matching capabilities resembling pattern matching in functional languages.

Best practice: Use pattern matching instanceof as a last resort when polymorphism via method overriding is not feasible. If you control the class hierarchy, prefer adding a method to the base type. If you don't, pattern matching is a clean, safe fallback.

package io.thecodeforge;

// Base class for geometric shapes — we cannot modify this (e.g., from a third-party library)
class Shape {
    double area() { return 0; }
}

class Circle extends Shape {
    double radius;
    Circle(double radius) { this.radius = radius; }
    @Override double area() { return Math.PI * radius * radius; }
}

class Rectangle extends Shape {
    double width, height;
    Rectangle(double width, double height) { this.width = width; this.height = height; }
    @Override double area() { return width * height; }
}

// A service that needs to handle shapes differently — simulating polymorphic dispatch via pattern matching
class ShapeRenderer {
    public void render(Shape shape) {
        // Java 16+ pattern matching eliminates the need for explicit cast
        if (shape instanceof Circle c) {
            System.out.println("Rendering circle with radius " + c.radius);
        } else if (shape instanceof Rectangle r) {
            System.out.println("Rendering rectangle " + r.width + "x" + r.height);
        } else {
            System.out.println("Unknown shape");
        }
    }
}

public class PatternMatchingExample {
    public static void main(String[] args) {
        ShapeRenderer renderer = new ShapeRenderer();
        renderer.render(new Circle(5.0));
        renderer.render(new Rectangle(3.0, 4.0));
    }
}

Polymorphism in Practice: Frameworks, Collections, and Real-World Patterns

You've already seen polymorphism in action whether you realised it or not. The Java Collections Framework is built on it: List interface with ArrayList, LinkedList, Vector — all behaving differently behind the same interface. Spring's @Transactional interception uses dynamic proxies (a form of polymorphism via interface implementation). Even the simple act of calling toString() on any object is polymorphism — the JVM dispatches to the actual class's override.

In design patterns, polymorphism is central: Strategy, Observer, Factory, Template Method all rely on runtime dispatch. The Strategy pattern, for instance, lets you swap an algorithm at runtime by passing different implementations of a common interface — exactly the pattern used in java.util.Comparator.

Knowing these patterns helps you recognise when to use polymorphism over conditional logic. If you find yourself writing if (type instanceof CreditCard) ... else if (type instanceof PayPal) ... you've missed the point. Replace that with a polymorphic call to a method on the common interface. That's the transformation that reduces code duplication and keeps your system open for extension.

package io.thecodeforge;

// Strategy interface — defines the polymorphic contract
interface ShippingCostStrategy {
    double calculateShipping(double weight, String destination);
}

// Concrete strategies
class StandardShipping implements ShippingCostStrategy {
    @Override
    public double calculateShipping(double weight, String destination) {
        return weight * 1.5 + 5.0;
    }
}

class ExpressShipping implements ShippingCostStrategy {
    @Override
    public double calculateShipping(double weight, String destination) {
        return weight * 3.0 + 10.0;
    }
}

class InternationalShipping implements ShippingCostStrategy {
    @Override
    public double calculateShipping(double weight, String destination) {
        return weight * 4.0 + 20.0;
    }
}

// Context class that uses polymorphism
class ShippingCalculator {
    private ShippingCostStrategy strategy;

    public ShippingCalculator(ShippingCostStrategy strategy) {
        this.strategy = strategy;
    }

    public double calculate(double weight, String destination) {
        return strategy.calculateShipping(weight, destination);
    }
}

public class StrategyPattern {
    public static void main(String[] args) {
        ShippingCalculator calc = new ShippingCalculator(new StandardShipping());
        System.out.println("Standard: $" + calc.calculate(10, "US"));

        calc = new ShippingCalculator(new ExpressShipping());
        System.out.println("Express: $" + calc.calculate(10, "US"));

        calc = new ShippingCalculator(new InternationalShipping());
        System.out.println("International: $" + calc.calculate(10, "UK"));
    }
}

Advantages and Disadvantages of Polymorphism in Java

Polymorphism is one of the cornerstones of object-oriented programming, but it comes with both strengths and trade-offs. Understanding these helps you decide when to use it and when to avoid over-engineering.

In practice, the performance overhead of dynamic dispatch is negligible compared to database calls or network I/O. The real cost is in readability when hierarchies become deep. Aim for shallow, well-documented hierarchies with clear contracts.

Practice Problems — Polymorphism in Action

The best way to internalise polymorphism is to design and implement a polymorphic system. Below are five practice problems ranging from classic to real-world inspired. Each tests your ability to choose between compile-time and runtime polymorphism, apply LSP, and refactor conditional logic into polymorphic dispatch.

### 1. Design a Shape Renderer

Create a class hierarchy for geometric shapes: Shape, Circle, Rectangle, Triangle. Each shape must implement methods area() and draw() (simulate drawing with a console string). Then write a ShapeRenderer class that takes an array of Shape objects and renders all of them without ever checking their concrete type. This tests runtime polymorphism via overriding.

Stretch goal: Add a new shape (e.g., Hexagon) later without modifying ShapeRenderer.

### 2. Build a Payment Gateway with Multiple Providers

Design a polymorphic payment system. Define an interface PaymentGateway with methods charge(double amount) and refund(String transactionId). Create implementations: StripeGateway, PayPalGateway, SquareGateway. Each must simulate processing with different fee structures. Write a PaymentService that accepts any PaymentGateway and executes payment flows. This tests interface-based polymorphism and the Strategy pattern.

Stretch goal: Add a TransactionLogger that wraps a PaymentGateway and logs every call — a decorator pattern using polymorphism.

### 3. Overloading Utility Methods for Different Data Sources

Implement a DataParser class with overloaded methods parse(String csvData), parse(byte[] jsonBytes), and parse(InputStream xmlStream). Each returns a List<Record> (define a simple Record class). The compiler should select the correct overload based on input type. This tests compile-time polymorphism and API ergonomics.

Stretch goal: Add parse(Path file) that auto-detects format from extension.

### 4. Refactor a Conditional Chain to Polymorphism

You are given legacy code that uses instanceof chains to handle different notification types (Email, SMS, Push). Refactor it into a polymorphic design with a Notification interface and an override send() method. Write unit tests to verify the refactored code behaves identically.

Stretch goal: Use the Java 16+ pattern matching instanceof as an intermediate step before full polymorphic refactoring.

### 5. Implement a Document Converter with Covariant Returns

Create a base class Document with fields title and content. Subclasses PDFDocument, WordDocument. Create a DocumentFactory with a method createDocument(String title, String content) that returns Document. Override it in a PDFDocumentFactory with covariant return type PDFDocument. The factories should also have a convert(Document doc) method that returns the converted document — use covariant returns for type safety.

Stretch goal: Add a DocumentConversionPipeline that chains multiple polymorphic converters.

Polymorphic Variables — How References Lie to You

A polymorphic variable is a reference variable that can hold objects of different types — but only if those types share an IS-A relationship. The compiler doesn't care what the actual object is; it only checks the declared type. This is why code can break at runtime if you assume the reference type tells you everything. You declare a variable as Animal, assign a Dog object, and the compiler only lets you call Animal methods. That Dog's fetch() method? Inaccessible. It's not a bug — it's the design enforcing that your code works with any Animal subtype. Spring Boot's Repository interface exploits this constantly: your UserRepository reference points to a SimpleJpaRepository at runtime, but your code only sees CrudRepository methods. This keeps your service layer decoupled from the persistence implementation. Use polymorphic variables to write code that doesn't care about the concrete type, but never forget: the reference type is a ceiling, not a floor. Cast if you must, but pattern match instead (Java 16+).

// io.thecodeforge
public class Animal {
    public void sound() { System.out.println("Animal sound"); }
}

public class Dog extends Animal {
    @Override
    public void sound() { System.out.println("Bark"); }
    public void fetch() { System.out.println("Fetching stick"); }
}

public class Main {
    public static void main(String[] args) {
        // Polymorphic variable: declared as Animal, holds Dog
        Animal myPet = new Dog();
        myPet.sound();          // Output: Bark (runtime dispatch)
        // myPet.fetch();       // Compile error! Animal has no fetch()
        
        // Safe cast with pattern matching (Java 16+)
        if (myPet instanceof Dog d) {
            d.fetch();          // Output: Fetching stick
        }
    }
}

Virtual Methods — The JVM's Late-Binding Secret

In Java, instance methods are virtual by default. That means the JVM doesn't decide which method to call at compile time — it waits until runtime, inspects the actual object's class, and calls the overridden version. This is late binding, and it's the engine behind all runtime polymorphism. Why does Java do this? Because you can't know at compile time which subclass will be instantiated. Your code calling animal.sound() doesn't know if animal is a Dog, Cat, or Cow. The JVM uses a virtual method table (vtable) per class, mapping method signatures to concrete implementations. When you call a method, the JVM looks up the vtable for the object's actual class and jumps directly to the implementation. This is cheap — a few CPU cycles — but it's not free. In hot paths with deeply nested overrides, the JIT compiler might inline the call if it can prove the object type. Spring Boot's @Transactional proxies rely on this: the proxy intercepts the call, opens a transaction, then delegates to the real method. If your method is private or final, Java doesn't treat it as virtual — the annotation silently fails.

// io.thecodeforge
public class PaymentProcessor {
    public void process(double amount) {
        System.out.println("Processing payment: " + amount);
    }
}

public class CreditCardProcessor extends PaymentProcessor {
    @Override
    public void process(double amount) {
        System.out.println("Charging credit card: " + amount);
    }
}

public class PayPalProcessor extends PaymentProcessor {
    @Override
    public void process(double amount) {
        System.out.println("Redirecting to PayPal: " + amount);
    }
}

@Service
public class PaymentService {
    private final PaymentProcessor processor;

    public PaymentService(PaymentProcessor processor) {
        this.processor = processor; // Injected as CreditCardProcessor at runtime
    }

    public void checkout(double amount) {
        processor.process(amount); // JVM looks up vtable -> CreditCardProcessor.process
    }
}