Java Polymorphism: Assignment Guide With Types & Examples

If you have a Java polymorphism assignment due and the whole "one method, many forms" idea still feels fuzzy, this guide is built for you. Polymorphism is one of the four pillars of object-oriented programming, and it shows up in almost every Java OOP assignment, lab, and exam right after you learn inheritance. Teachers love it because it quickly shows whether you really understand how objects and methods work together, or whether you are just copying patterns.

This guide explains polymorphism in plain English, shows you both types with code you can run today, walks through a complete assignment solved from start to finish, and points out the exact mistakes that quietly cost students marks. By the end you will be able to write a solution you can actually explain if your instructor asks you questions about it.

What Is Polymorphism in Java? (In Simple Words)

The word polymorphism comes from two Greek words: "poly" meaning many, and "morph" meaning form. So polymorphism just means "many forms." In Java, it means one method name can do different things depending on the situation.

Here is an everyday way to picture it. Think about the word "run." A person runs, a car engine runs, and a program runs. Same word, different action each time, and you understand which one is meant from the context. Java does the same thing with methods. You call one method name, and Java figures out the right version to actually run.

Polymorphism almost always builds on inheritance, so if class hierarchies still feel shaky, it helps to review Java inheritance first, since polymorphism is the payoff that inheritance sets up.

Why Polymorphism Shows Up in Your Assignments

Teachers assign polymorphism problems to test whether you can write flexible code that treats many object types through a single, clean interface. When a rubric mentions "method overloading," "method overriding," "dynamic behavior," or asks you to "process a list of different objects the same way," polymorphism is what is being graded.

The main things your assignment is usually asking you to prove are:

• You can write one method name that handles different inputs (overloading).
• You can let a child class change inherited behavior (overriding).
• You can store different object types in one parent-type array or list and still call the correct behavior for each.
• You understand the difference between a choice Java makes while compiling and a choice it makes while running.

Key Terms You Need Before You Write Any Code

Learn these words, because rubrics and exam questions use them directly.

The Two Types of Polymorphism in Java

Java has exactly two types of polymorphism, and almost every assignment asks about both. The whole "compile-time vs runtime" question that professors love comes down to when Java decides which method to run.

Compile-time polymorphism is decided before the program runs, based on the method signature you wrote. Runtime polymorphism is decided while the program runs, based on the actual object in memory. Let us look at each one with code.

Compile-time Polymorphism (Method Overloading)

Compile-time polymorphism happens through method overloading. You write several methods with the same name in one class, but each takes a different set of parameters. Java looks at the arguments you pass and picks the matching version while it compiles. Because the choice is locked in before the program runs, it is also called static binding or early binding.

class Calculator {
    // same name, two int parameters
    int add(int a, int b) {
        return a + b;
    }

    // same name, two double parameters
    double add(double a, double b) {
        return a + b;
    }

    // same name, three int parameters
    int add(int a, int b, int c) {
        return a + b + c;
    }
}

public class Overloading {
    public static void main(String[] args) {
        Calculator calc = new Calculator();
        System.out.println(calc.add(5, 3));        // uses the two-int version
        System.out.println(calc.add(2.5, 1.5));    // uses the two-double version
        System.out.println(calc.add(1, 2, 3));     // uses the three-int version
    }
}

Notice that the method name never changes. Java tells the three versions apart by the number and type of the parameters. That set of details is called the method signature. Overloading does not need inheritance at all, which is one of the easiest ways to remember that it is different from overriding.

Runtime Polymorphism (Method Overriding)

Runtime polymorphism happens through method overriding. A child class rewrites a method it inherited, keeping the exact same name and parameters but changing what the method does. Java does not decide which version to run until the program is actually running and it can see the real object. That is why it is called dynamic binding or late binding.

class Animal {
    void makeSound() {
        System.out.println("Some animal sound");
    }
}

class Dog extends Animal {
    @Override
    void makeSound() {
        System.out.println("Woof");
    }
}

class Cat extends Animal {
    @Override
    void makeSound() {
        System.out.println("Meow");
    }
}

public class Runtime {
    public static void main(String[] args) {
        // The array type is Animal, but the objects are Dog, Cat, and Animal.
        Animal[] animals = { new Dog(), new Cat(), new Animal() };

        for (Animal a : animals) {
            a.makeSound();   // Java runs the correct version for each real object
        }
    }
}

This is the heart of runtime polymorphism. The variable type is Animal, but Java looks at the real object sitting in memory and runs that object's version of makeSound(). Always add the @Override annotation above the method. It tells the compiler to double-check that you are truly overriding a parent method, so a typo turns into a clear error instead of a silent bug.

Method Overloading vs Method Overriding (Quick Comparison)

Students mix these two up more than any other part of the topic, and graders test the difference on purpose. Here is a clean side-by-side.

The fastest way to remember it: if the parameter list is different, it is overloading. If the parameter list is identical across a parent and child, it is overriding.

A Complete Worked Assignment: Shape Area Calculator

Many polymorphism assignments use shapes, animals, payments, or vehicles. Let us solve a realistic shape assignment from start to finish, because it shows both overloading and overriding in one program, which is exactly what many rubrics want to see.

The task: Create a Shape base class with an area() method. Add Rectangle and Circle classes that override area() with their own formula. The Rectangle should also support a shortcut where passing one number makes a square. Store several shapes in one array and print each area.

Figure 1: UML Class Diagram structure illustrating polymorphism inheritance hierarchy.

class Shape {
    private String name;

    Shape(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }

    // Base version. Child classes override this with a real formula.
    public double area() {
        return 0;
    }
}

class Rectangle extends Shape {
    private double length;
    private double width;

    // Constructor for a normal rectangle
    Rectangle(double length, double width) {
        super("Rectangle");
        this.length = length;
        this.width = width;
    }

    // Overloaded constructor: one value makes a square (compile-time polymorphism)
    Rectangle(double side) {
        super("Square");
        this.length = side;
        this.width = side;
    }

    // Overriding the parent method (runtime polymorphism)
    @Override
    public double area() {
        return length * width;
    }
}

class Circle extends Shape {
    private double radius;

    Circle(double radius) {
        super("Circle");
        this.radius = radius;
    }

    @Override
    public double area() {
        return 3.14159 * radius * radius;
    }
}

public class ShapeReport {
    public static void main(String[] args) {
        // One Shape array holds three different object types.
        Shape[] shapes = {
            new Rectangle(5, 3),   // rectangle
            new Rectangle(4),      // square, uses the overloaded constructor
            new Circle(2)          // circle
        };

        // The loop calls area() on each shape and Java runs the right version.
        for (Shape s : shapes) {
            System.out.println(s.getName() + " area = " + s.area());
        }
    }
}

Look at how much this one program proves. The two Rectangle constructors are overloading, which is compile-time polymorphism. Each shape overrides area(), which is runtime polymorphism. The loop treats every object as a Shape but still runs the correct formula for each real object, which is dynamic method dispatch in action. If your assignment uses payments, animals, or vehicles instead, the structure is the same. Swap the class names and the formulas, and keep the pattern.

One thing to tell any student running this: the file must be saved as ShapeReport.java, because that is the public class name. Save it under any other name and Java throws a "class ShapeReport is public, should be declared in a file named ShapeReport.java" error before it even runs.

What Your Professor Actually Grades in a Polymorphism Assignment

Here is the part almost every competing guide skips, and it is the part that decides your grade. Graders rarely hand out full marks just because the program compiles and prints something. Based on how OOP rubrics are usually written, points are spread across a few areas, and students lose them in the same predictable spots every term.

Most rubrics reward five things. First, correct use of both types, meaning you show overloading and overriding where the task asks, and you do not confuse one for the other. Second, real dynamic behavior, meaning you actually store child objects in a parent-type variable or array and call the overridden method through it, since that is the only way to prove runtime polymorphism instead of just writing two unrelated methods. Third, the @Override annotation used correctly, which signals that you understand overriding and not just method copying. Fourth, output that matches the sample the assignment gave you, including spacing and decimals. Fifth, short, clear comments on the parts that carry the real logic. If the task also asks for a UML diagram or a written explanation of where each type of polymorphism appears, treat that as its own graded item, because it is often worth more points than students expect.

The quiet grade-killers are just as predictable. Writing two methods with the same name but forgetting to actually call them through a parent reference means you demonstrated overloading but never proved runtime polymorphism, and you lose half the marks. Forgetting @Override can hide a spelling mistake that silently creates a brand new method instead of overriding the parent one. Calling child methods directly on child variables, instead of through a parent-type variable, technically works but fails to show the dynamic dispatch the rubric is testing. Knowing this list before you submit lets you check your own work the way your teacher will.

Things That Look Like Polymorphism But Are Not

This is the second point almost no ranking guide explains clearly, and understanding it will set your assignment apart, because it is exactly the trap that turns an A into a B. Not everything that looks flexible in Java is real polymorphism, and graders love to test the edges.

The biggest trap is field hiding. Fields in Java are never polymorphic. Only methods are. If a parent and child both declare a field with the same name, Java picks the field based on the variable type, not the real object.

class Parent {
    String label = "Parent";
}

class Child extends Parent {
    String label = "Child";
}

public class FieldHiding {
    public static void main(String[] args) {
        Parent p = new Child();
        System.out.println(p.label);   // prints "Parent", not "Child"
    }
}

Even though the object is really a Child, this prints Parent, because fields follow the reference type. Many students expect Child here and get the wrong answer on a quiz. The rule to remember is simple: methods are polymorphic, fields are not. The other common trap is static methods, which cannot be overridden in the polymorphic sense. If you declare a static method with the same signature in a child class, that is method hiding, not overriding, and it also follows the reference type rather than the object. If your assignment has you reasoning about behavior, keep the real logic in regular instance methods so polymorphism actually works.

Steps and Mistakes to Avoid While Working on This Topic

Keep this checklist next to you while you code your assignment.

• Do not confuse overloading with overriding. Different parameters is overloading. Identical parameters across parent and child is overriding.
• Do not forget the @Override annotation on overridden methods. It catches typos before they become bugs.
• Do not call your overridden method directly on a child variable and think you proved runtime polymorphism. Call it through a parent-type variable or array.
• Do not try to override a static, final, or private method. Java does not allow it, and it will not behave polymorphically.
• Do not expect fields to behave polymorphically. They follow the variable type, not the object.
• Do not change the method signature when overriding. Even a small difference turns your override into an accidental overload.

Common Polymorphism Errors and How to Fix Them

These are the compiler messages that show up most often in polymorphism homework, with the fix.

• "method does not override or implement a method from a supertype." Your @Override method does not match any parent method exactly. Check that the name, return type, and parameters are identical to the parent version.
• "reference to add is ambiguous" during overloading. Two overloaded methods match your arguments equally well, so Java cannot choose. Make the parameter types clearer or cast your argument to the type you want.
• The parent version runs when you expected the child version. You probably overloaded (different parameters) instead of overriding (same parameters), or you forgot @Override. Match the signatures exactly.
• A field shows the parent value unexpectedly. That is field hiding, not a bug. Fields are not polymorphic. Use a method to return the value instead.

How to Test Your Polymorphism Code Before Submitting

Do not submit after a single run. First, create objects of each child class and call the overloaded methods with different arguments to confirm each version runs. Then store your child objects in a parent-type array or list and loop through them, calling the overridden method, to confirm each object runs its own version. If the loop prints the correct behavior for every object, your runtime polymorphism is working. Finally, check your output against the assignment's sample output character by character, since spacing and decimal places often get compared directly during grading.

Viva Questions on Polymorphism (With Sample Answers)

Many courses ask you to defend your assignment in a short viva, where the teacher asks questions to check that you actually wrote and understood your code. Here are five questions that come up again and again on this topic, along with short answers you can say in your own words.

If you want to rehearse questions like these before your real viva, DMCH also has a free Viva Defense Simulator you can practice with.