Interfaces, abstract classes, and polymorphism

An interface declares what a type can do; it cannot hold instance state. An abstract class can hold state and share real implementation, but a class can only extend one of them — Java has single inheritance for classes, unlimited for interfaces.

interface Shape {
    double area();
    default String describe() {          // a real, shared implementation
        return "area=" + area();
    }
}

abstract class Animal {
    protected final String name;          // real state
    Animal(String name) { this.name = name; }
    abstract String sound();               // no implementation yet
    String describe() { return name + " says " + sound(); }
}

A default method on an interface gives it a body that implementers inherit for free and may override — the mechanism that let the collections framework add forEach and stream() to every existing List without breaking a single class that already implemented it.

Try it

Polymorphism: one call site, many behaviours

List<Shape> shapes = List.of(new Circle(2), new Square(3));
double total = 0;
for (Shape s : shapes) {
    total += s.area();   // which area() runs is decided at runtime
}

The loop does not know or care whether each element is a Circle or a Square. s.area() dispatches to whichever class's implementation the object actually is, decided at runtime by the object's real type, not by the variable's declared type Shape. This is what makes adding a Triangle later free at every existing call site: nothing that already calls .area() on a Shape needs to change.

Programming to the interface

List<String> names = new ArrayList<>();   // not: ArrayList<String> names

Declaring the variable as the interface type, even though the concrete class is known, is the convention for a reason: every place that reads names only ever depends on what List promises, so swapping ArrayList for LinkedList later touches one line instead of every call site that happened to know the concrete type.