Java Inheritance, Interfaces and Polymorphism

Inheritance creates a subclass from an existing superclass. In class Student extends Person, every student is a person. A student object holds its person state and its extra student state together in one object.

Add the student-specific parts

Here is a small superclass and a subclass:

class Person {
    private String name;
    public Person(String name) { this.name = name; }
    public String getName() { return name; }
}

class Student extends Person {
    private int credits;
    public Student(String name) { super(name); }
    public void study() { credits += 5; }
    public int getCredits() { return credits; }
}

Student inherits getName(). It adds a credits field and two methods. After Student s = new Student("Ada Lovelace");, the credits field starts at 0. Two calls to s.study() raise it first to 5 and then to 10. s.getName() still returns "Ada Lovelace": the inherited method reads the private field declared in Person.

The statement super(name) passes the name to the Person constructor. Constructors are not inherited, so Student declares its own constructor. A subclass may add methods and override inherited behavior, but it cannot remove an inherited public method from its public API.

Know which members are accessible

Private members are not inherited. The private name field still exists inside each student, but Student cannot read it directly. Keeping the field private and providing a getter lets Person control its own data. Across packages, protected instance access has an extra restriction: subclass code accesses the member through itself or a reference of its own subclass type, not through an arbitrary superclass reference.

Test the relationship before extending

Java allows one direct superclass per class. A chain such as GraduateStudent extends Student and Student extends Person is valid; extends Student, Teacher is not. A class with no explicit superclass extends Object. Object itself has no superclass.

Use the is-a test: can every subclass object be used wherever the superclass is expected? A truck is a vehicle. A customer has an address, but a customer is not an address. For that second relationship, use composition:

class Customer {
    private Address address;
}

Here Address is another class. The field lets a customer use an address without claiming to be one. Extending a class just to borrow a convenient method also inherits its whole public contract. Finally, a final class cannot be extended. Because String is final, class ShortString extends String fails to compile.

A subclass constructor must arrange construction of the superclass part of the same object. It can call a superclass constructor with super(...), or delegate to another constructor in its own class with this(...).

Choose the superclass constructor

class Person {
    private final String name;
    Person(String name) { this.name = name; }
}
class Student extends Person {
    private final String studentId;
    Student(String name, String studentId) {
        super(name);
        this.studentId = studentId;
    }
    Student(String name) {
        this(name, "no id yet");
    }
}

The two-argument constructor passes the name to Person and stores the ID itself. The one-argument constructor delegates to it. A constructor contains at most one explicit constructor invocation: this(...) or super(...). Following the this(...) chain eventually reaches a constructor that invokes super(...).

If neither is written, Java inserts super(). That fails here because Person has only a constructor requiring a name. Declaring any constructor prevents Java from supplying a default no-argument constructor. A class with no declared constructor gets a default one that calls super().

Writing new Person(name) inside Student does something else: it constructs a separate object. It does not initialize the current student's person state or replace the required superclass constructor call.

Trace initialization in order

class Base {
    Base() { System.out.println("Base ready"); }
}
class Middle extends Base {
    Middle() { System.out.println("Middle ready"); }
}
class Top extends Middle {
    Top() { super(); System.out.println("Top ready"); }
}

new Top() enters the constructor chain up to Object. As calls return, the output is "Base ready", "Middle ready", then "Top ready". Each class's field initializers run after its superclass constructor returns and before that class's remaining constructor body.

An overridable method called by a superclass constructor can already run a subclass override. If that override reads a subclass reference field whose assignment has not run, it sees null, even if the field has a declaration initializer. Keep constructor work to setting up state; avoid calls to methods subclasses can override.

Recognize the Java 25 change

In Java 25, a constructor can validate parameters before its explicit constructor invocation:

Student(String name, String studentId, int credits) {
    if (credits < 0) {
        throw new IllegalArgumentException("negative credits");
    }
    super(name);
    this.studentId = studentId;
}

Java 25 also allows simple early assignments to fields declared in the current class without declaration initializers. It still forbids reading the current object's fields, calling its instance methods, or passing this around before the invocation. For standard language levels before Java 25, keep super(...) or this(...) first. Java 22–24 offered earlier forms as preview features.

An override gives a subclass its own implementation of an inherited instance method. Its name and parameter types match the original method, so callers can keep using the same operation.

Extend a working method

Suppose an employee's yearly pay is twelve monthly payments. A manager also receives a yearly bonus:

class Employee {
    private final double monthlySalary;
    Employee(double monthlySalary) {
        this.monthlySalary = monthlySalary;
    }
    public double yearlyPay() { return 12 * monthlySalary; }
}
class Manager extends Employee {
    private final double bonus;
    Manager(double monthlySalary, double bonus) {
        super(monthlySalary);
        this.bonus = bonus;
    }
    @Override
    public double yearlyPay() {
        return super.yearlyPay() + bonus;
    }
}

For new Manager(3000.0, 5000.0), the superclass call returns 36000.0. Adding 5000.0 gives 41000.0. super.yearlyPay() deliberately selects the superclass implementation. The superclass method remains available inside the subclass even though ordinary calls on the manager run the override.

Writing return yearlyPay() + bonus; calls the manager's own method again. No call finishes, so execution eventually fails with StackOverflowError. The missing super. changes the meaning of the call.

Let the compiler check the signature

Put @Override above each overriding method. A misspelling such as yearlypay() or an extra parameter then causes a compile error. Without the annotation, Java may accept a new method that callers never use.

A valid override follows these rules:

• Its parameter types match exactly.
• Its return type is the same, or a subtype when returning an object type. That permitted narrowing is a covariant return type.
• Its access is at least as open as the inherited method's access.
• It does not add checked exceptions that the inherited declaration forbids.

For example, public String toString() cannot be replaced with package-private String toString(). Existing callers must retain access.

Separate overriding from overloading and hiding

role() and role(String language) are overloads; the second does not replace the first. Overload choice uses declared argument types at compile time. Static methods are also selected from the type used at compile time, so they are not dynamically overridden.

A private method is not inherited; a same-named subclass method is independent. A final method cannot be overridden, and constructors cannot be overridden. Beyond compiling, the method must still fulfill its original purpose. A manager override that returns monthly pay would break code that totals yearly pay even if its signature were correct.

Every Java class extends Object directly or indirectly. Arrays are objects too. This shared root provides methods such as toString(), equals(Object), hashCode() and getClass() even when a class declares none of them.

Replace the default printed description

The inherited Object.toString() produces a class name, @, and the object's hash code in hexadecimal. Text such as "school.Person@1b6d3586" identifies the class but does not explain the person's data. The number may change across runs and is not a memory address promised by Java.

A useful override shows the fields readers need. Here a student has inherited getName() and stores a credits field:

@Override
public String toString() {
    return getName() + " (" + credits + " credits)";
}

For a student named Ada Lovelace with 10 credits, System.out.println(s) prints "Ada Lovelace (10 credits)". The print call obtains the object's text automatically. String concatenation does this too: "Student: " + s includes the same description.

For a null reference, printing and concatenation produce "null". An explicit call s.toString() when s is null throws NullPointerException, because there is no object to receive that call.

If Person.toString() already returns the person's name, a subclass can build on it:

@Override
public String toString() {
    return super.toString() + ", student id " + studentId;
}

For ID "S-17", that produces "Ada Lovelace, student id S-17". The usefulness of super.toString() depends on what the superclass actually returns. If it still uses Object's version, it contributes the default class-and-hash text.

Keep identity and class information separate

Object.equals(Object) compares identity: it returns true when both references refer to the same object. Two separate new Person("Ada") objects are not equal under that inherited implementation, despite having matching names. Classes such as String, Integer and ArrayList supply value-based overrides.

getClass() reports the actual runtime class:

Person p = new Student("Ada Lovelace");
System.out.println(p.getClass().getSimpleName());

This prints "Student" when Student has the constructor shown. The variable's declared type does not alter the object's class. getClass() is final and cannot be overridden.

hashCode() supports hash-based collections. Other methods from Object include the protected clone() and the thread-coordination methods wait(), notify() and notifyAll().

Check exact spelling

Java distinguishes toString() from tostring(). A method toString(String prefix) is an overload, so printing does not call it. Both mistakes are caught by @Override. A text representation also does not define equality: two objects can print the same text while still comparing unequal.

Two objects can represent the same value without being the same object. A book catalog can treat two book objects as equal when their catalog code and edition match. Define that rule by overriding equals(Object) and keep hashing consistent with it.

Compare the fields that define the value

import java.util.Objects;

final class Book {
    private final String code;
    private final int edition;
    Book(String code, int edition) {
        this.code = code;
        this.edition = edition;
    }
    @Override
    public boolean equals(Object other) {
        if (this == other) return true;
        if (!(other instanceof Book b)) return false;
        return edition == b.edition && Objects.equals(code, b.code);
    }
    @Override
    public int hashCode() {
        return Objects.hash(code, edition);
    }
}

The identity check accepts the same object quickly. The type check rejects an unrelated object or null, then introduces b as a Book. Primitive editions use ==; Objects.equals compares codes safely even when a code is null. Two books with code "B-1042" and edition 2 compare equal. Edition 3 makes a different value.

The parameter must be Object. Writing equals(Book other) adds an overload; it leaves the inherited equals(Object) in place. Library code calling that signature would still compare identity. @Override makes the wrong declaration fail at compile time.

Follow the equality promises

For non-null references, equality must be:

• Reflexive: an object equals itself.
• Symmetric: switching the two objects gives the same answer.
• Transitive: if one equals a second and the second equals a third, the first equals the third.
• Consistent: repeated comparisons agree while the compared data stays unchanged.

An object must also compare unequal to null. Equal objects must return equal hash codes. Unequal objects are allowed to share a hash code: a hash collision does not establish equality. Derive the hash from the same fields as equality, as Objects.hash(code, edition) does here.

A hash collection uses the hash to locate candidates before checking equality. Overriding only equals can make a set retain separate equal books or make a map fail to find an equal key. Changing a field used in hashing while its object is stored as a key can leave that object filed under its old hash.

Protect symmetry across subclasses

Suppose an extensible Book accepts any instanceof Book, while Ebook adds file size to equality and accepts only ebooks. A book may accept an ebook with the same code and edition, but the ebook rejects the book. The comparison has lost symmetry.

One approach requires matching runtime classes, checking null before getClass(). Another makes superclass equality final so subclasses cannot extend the equality rule. A final value class, as above, avoids subclass equality entirely. Records generate equality and hashing from their components; enum constants already have identity-based equality suited to their fixed values.

An abstract class is a base class that cannot be instantiated directly. It can hold common fields and working methods while leaving selected operations for subclasses to complete.

Leave a required operation abstract

abstract class Shape {
    private final String name;
    Shape(String name) { this.name = name; }
    public abstract double area();
    public String describe() {
        return name + " with area " + area();
    }
}
class Rectangle extends Shape {
    private final double width;
    private final double height;
    Rectangle(double width, double height) {
        super("rectangle");
        this.width = width;
        this.height = height;
    }
    @Override
    public double area() { return width * height; }
}

area() has a signature and a semicolon, with no body. It states what every concrete shape must provide. Because Shape contains an abstract method, the class must be abstract too. Rectangle supplies the missing implementation and can be instantiated.

For new Rectangle(3.0, 4.0), the superclass constructor stores "rectangle". The subclass constructor stores the dimensions. Its area is 12.0 square meters when dimensions are in meters. Calling describe() returns "rectangle with area 12.0". The inherited method's call to area() runs the rectangle's implementation.

Use constructors and concrete methods normally

An abstract class can have fields, constructors, and methods with bodies, with the usual access levels. Its constructor runs as part of creating a subclass object. new Shape() is forbidden even if a matching constructor exists; new Rectangle(3.0, 4.0) is valid.

A second subclass can use the same inherited description while calculating area differently. A circle implementation returns Math.PI * radius * radius. For radius 1.5 m, the calculation is π times 2.25, about 7.07 square meters. The shared describe() method needs no circle-specific branch.

A variable can still have the abstract type: Shape s = new Rectangle(3.0, 4.0);. Java forbids constructing the abstract class, not referring to a concrete object through it.

Make missing work a compile error

Every concrete subclass must provide or inherit implementations of all abstract methods. A subclass that leaves some unfinished must also be declared abstract. Returning 0 from a placeholder area() would let an incomplete concrete subclass compile and silently give wrong results. Declaring area() abstract makes that missing work visible to the compiler.

Abstract methods cannot be private, static or final: each would prevent the subclass override that supplies the operation. An abstract class may contain no abstract methods; the modifier then only prevents direct construction. Use this kind of base class when its subclasses pass the is-a test and benefit from shared state or code.

An interface names a capability that several classes can provide. It states the methods available through that capability without requiring the classes to share the same instance fields or superclass.

Declare and implement the methods

interface Chargeable {
    int batteryPercent();
    void charge(int minutes);
}
class Phone implements Chargeable {
    private int battery;
    Phone(int battery) { this.battery = battery; }
    @Override
    public int batteryPercent() { return battery; }
    @Override
    public void charge(int minutes) {
        battery = Math.min(100, battery + 2 * minutes);
    }
}

The interface's abstract methods are implicitly public. The implementing methods must explicitly be public; omitting that modifier would reduce access and fail compilation. A concrete class must supply or inherit suitable public implementations of every abstract method. An abstract implementing class may leave some for its subclasses.

For a phone at 35 percent, charge(20) adds 40 percentage points and leaves 75 percent. Another 20 minutes would reach 115 before the cap, so Math.min stores 100. An ElectricScooter can implement the same interface while adding only one point per minute: starting at 50 percent, it reaches 70 after 20 minutes. The interface fixes the available operation, while the class supplies its behavior.

Use the interface as a type

Chargeable device = new Phone(35);
device.charge(20);
System.out.println(device.batteryPercent());

This prints 75. A caller can use the interface's methods and the public methods available on every object. Phone-only operations are not available through device unless the declared interface exposes them.

Interfaces can also be parameter, return, and list element types. A method accepting Chargeable can work with a phone or a scooter without knowing their field layouts. Java's library uses the same approach: List has implementations such as ArrayList and LinkedList; Runnable declares run(); Comparable declares natural comparison.

Combine more than one capability

A class extends one class and may implement several interfaces. The order is class Phone extends Device implements Chargeable, Connectable. An interface can extend several interfaces: interface SmartDevice extends Chargeable, Connectable. Implementers then owe all the inherited abstract operations.

An interface has no constructors and no instance fields. new Chargeable() does not compile. A declared field such as int FULL = 100; is implicitly a public static final constant, read as Chargeable.FULL.

An abstract interface method contributes no working code. Its implementation may come from the class itself or an inherited public superclass method. Default methods are the interface methods that can supply inherited instance behavior.

Interfaces can supply working code as well as abstract method declarations. The method's modifier decides whether implementing objects inherit it, callers use the interface name, or only code inside the interface can use it.

Build default behavior from the contract

interface Chargeable {
    int batteryPercent();
    void charge(int minutes);
    default boolean needsCharge() {
        return batteryPercent() < 20;
    }
    static int clamp(int percent) {
        return Math.max(0, Math.min(100, percent));
    }
}

A default method is a public instance method with a body. A phone reporting 15 percent inherits needsCharge() and returns true. At 20 percent it returns false. The default calls the abstract batteryPercent() operation; it does not read a phone's private field. A class may override the method with its own public implementation.

A static interface method belongs to the interface: Chargeable.clamp(130) returns 100 and Chargeable.clamp(-5) returns 0. Implementing classes do not inherit it, so Phone.clamp(130) is not a valid call to this method. Default and static interface methods were introduced in Java 8.

Since Java 9, an interface may also declare private methods to share helper code among its own methods. A private instance helper supports default methods; a private static helper can also support static methods. Implementing classes cannot call these helpers directly.

Resolve competing defaults

Two unrelated interfaces can supply the same signature:

interface Lamp {
    default String describe() { return "lamp"; }
}
interface Speaker {
    default String describe() { return "speaker"; }
}
class SmartLamp implements Lamp, Speaker {
    @Override
    public String describe() {
        return Lamp.super.describe() + " and "
             + Speaker.super.describe();
    }
}

Without the override, SmartLamp has a conflict and does not compile. The qualified InterfaceName.super.method() calls select the individual defaults from its direct superinterfaces. This implementation returns "lamp and speaker".

An abstract superclass declaration can also require a concrete subclass to implement the method; an interface default does not remove that obligation.

Consider existing implementers

Adding an abstract method requires each concrete implementer to provide or inherit a matching implementation. A default often avoids that change by supplying working behavior, but it can introduce a conflict with another inherited method. Defaults help an interface evolve; the inheritance rules still determine whether the resulting classes compile.

An abstract class and an interface can both define required methods. The choice depends on the relationship between objects and whether their implementation needs shared instance state.

Compare what each one supplies

Interface fields are public static final constants, not per-object data. Private interface helpers support its own working methods; they do not create private state for each implementing object.

Put closely related state in an abstract class

A drawing program has circles, rectangles and triangles. Each shape stores a name and a position, and each computes its area differently. An abstract Shape can keep the common fields and constructor, provide working movement or description methods, and declare area() abstract.

All concrete shapes are kinds of Shape, so other code can ask for a shape and receive any of them. Similarly, an abstract Enemy might own health points and a shared takeDamage(int points) method while leaving movement to particular enemy classes. The shared state gives these base classes useful work to do.

Put a cross-cutting capability in an interface

The same drawing program can export shapes, text labels and images. Exporting does not make a text label a shape, and these objects may already need different superclasses. An Exportable interface can declare String exportText(). Each class implements the operation using its own data.

A class may combine the two roles: class Circle extends Shape implements Exportable. The superclass provides shape state and shared code; the interface makes the circle usable by export code. A class implementing several interfaces promises several capabilities without inheriting instance fields from them.

Combine a contract with a partial implementation

An abstract class can implement an interface and complete only some methods. Concrete subclasses finish the remaining operations. Java's List and AbstractList use this arrangement; ArrayList extends AbstractList. Callers can depend on the interface while implementers reuse a base class where it fits.

For example, List<String> names = new ArrayList<>(); lets callers add, read and remove names through List. Replacing the initializer with new LinkedList<>() preserves those calls. A parameter declared as ArrayList<String> would reject a LinkedList<String> even when it only needs list operations.

An abstract class containing only abstract methods still occupies the subclass's single superclass slot. It is not interchangeable with an interface. Choose the interface when only the common contract is needed, and add a base class when related implementations benefit from shared state or code.

Polymorphism lets a general reference point to objects of different subtypes. The object keeps its full state and behavior; the reference gives callers a particular view of the available operations.

Name the two types

Person p = new Student("Ada Lovelace", "S-17");

The declared type, also called the static type, is Person: it appears in the variable declaration. The actual type, or runtime type, is Student: that is the class instantiated by new. The object's actual class does not change after construction.

Assigning a student reference to a person reference is an upcast. It is automatic and safe because every student is a person. The same student can also be referred to by an Object variable. An implementing object can be upcast to an interface it implements, as in Chargeable c = new Phone(35);.

No student data is deleted by the assignment. There is still one student object with its student ID, inherited person data and overridden methods. Giving it a more general reference changes what the compiler lets that reference access.

Check calls against the declared type

If Person declares getName(), then p.getName() compiles. If only Student declares getStudentId(), then p.getStudentId() does not compile. The compiler checks the Person API even when the initializer clearly creates a student.

The reverse assignment Student s = p; is not accepted without a cast. A person reference could point to a non-student person. That restriction protects code from treating an object as a subtype it does not have.

Let parameters and lists accept several subtypes

A method static void printCard(Person person) can receive a Person, Student or Teacher object, assuming those last two extend Person. Its code can rely on the person contract. A return type can be general too, for example a method that returns a Shape.

A list with a general element type can store different shape classes:

List<Shape> shapes = new ArrayList<>();
shapes.add(new Circle(1.5));
shapes.add(new Rectangle(3.0, 4.0));
for (Shape shape : shapes) {
    System.out.println(shape.area());
}

Here List and ArrayList come from java.util, and each concrete shape supplies area(). The loop uses only that common operation.

A List<Circle> is not a List<Shape>. If it were, code receiving it as a shape list could add a rectangle into a list promised to contain only circles. When a method requires List<Shape>, create the list with that element type from the start.

A method call is resolved in two stages. At compile time, Java checks the declared types and chooses a method signature. At run time, dynamic binding chooses the overriding instance-method implementation for the object's actual class.

Follow a call inside an inherited method

class A {
    String who() { return "A"; }
    String hello() { return "Hello from " + who(); }
}
class B extends A {
    @Override String who() { return "B"; }
}
class C extends B { }

For A x = new C();, x.hello() is allowed because A declares hello(). Class C has no override of hello(), nor does B, so Java runs the implementation in A.

Inside that method, who() means this.who(). The receiver is still the C object. Java searches from C, then finds the nearest who() implementation in B. The result is "Hello from B". Entering an inherited method does not turn the receiver into an object of the superclass.

Choose an overload before choosing an override

static String kind(Object value) { return "object"; }
static String kind(String value) { return "string"; }

Inside a class containing these methods, Object value = "hi"; kind(value) selects kind(Object) and returns "object". The variable's declared type is Object; Java does not reconsider overloads using the actual string at run time.

For an instance call, runtime dispatch can still choose an override of the already-selected signature. It cannot switch to a different overload that merely looks more specific for the actual argument. First identify the signature, then look for its override.

Recognize calls and members that do not dispatch this way

If P declares String label = "P"; and Q extends P declares its own String label = "Q";, then P p = new Q(); p.label reads "P". Fields are hidden, not overridden. Both fields exist in the object. Avoid reusing inherited field names because the reference type can make identical-looking accesses read different state.

super.method() selects the superclass implementation, including one that superclass inherits. If the selected method itself makes an ordinary call on this, that inner call can still dispatch to a subclass override.

A general reference sometimes needs access to an operation that belongs only to one subtype. A downcast tells the compiler to treat the reference as that subtype. At run time, Java checks whether the object already has that type.

Understand what a cast changes

Suppose Person p refers to a student. Student s = (Student) p; allows s.getStudentId(). Both variables still refer to the same object. The cast does not copy it, change its actual class, or add student fields to a plain person.

If p actually refers to new Person("Grace Hopper"), that cast throws ClassCastException. A compiler accepts the possible person-to-student relationship, but the runtime object must still meet it. A cast between classes that cannot be related, such as a Person reference cast to the final class Integer, fails at compile time.

This differs from a primitive conversion: (int) 3.9 creates the integer value 3. A reference cast only checks and changes the type through which an existing reference is used.

Combine the test and the new variable

Since Java 16, pattern matching makes the safe case compact:

static void showStudentId(Person person) {
    if (person instanceof Student student) {
        System.out.println(student.getStudentId());
    }
}

The test is true for a student or a subclass of student. The variable student is available inside the block, where the test is known to have succeeded. A plain person skips the block. A null reference also makes the test false, so the block never tries to call a method on null.

The older form tests person instanceof Student and then declares Student student = (Student) person; inside the successful branch. Both forms protect the cast. Testing an unrelated object elsewhere does not protect a cast of person; the test and cast must concern the same reference.

An upcast needs no explicit cast. Person person = student; already compiles and cannot fail from a type mismatch. A cast of null to a compatible reference type produces null; using that result for an instance-method call still fails with NullPointerException.

Decide whether a type test is needed

Type tests fit code that receives an Object, such as equals(Object other), or needs a subtype-only operation such as a student ID. They can also help when working with classes that cannot be changed.

A repeated type-test chain for a shared operation is a different problem. If code checks for each shape class to calculate its area, every added shape requires another branch. Declaring area() on Shape and letting subclasses implement it lets the caller use shape.area() instead.

A cast cannot make a missing common operation available across every subtype. Put shared behavior in the common contract, and reserve a subtype test for work that actually requires that particular subtype.

A method stays useful across new classes when its parameter exposes exactly the operations the method needs. The caller supplies objects; dynamic binding supplies their individual behavior.

Add areas without class-specific branches

static double totalArea(List<Shape> shapes) {
    double total = 0;
    for (Shape shape : shapes) {
        total += shape.area();
    }
    return total;
}

With a circle of radius 1.5 m, a rectangle of dimensions 3.0 m and 4.0 m, and a triangle of base 4.0 m and height 2.5 m, the areas are about 7.06858, 12.0 and 5.0 square meters. Adding the unrounded circle area gives about 24.07 square meters. Each object supplies its own area().

Adding a Triangle class does not require editing the loop. The new class implements the existing shape operation. A negative result would violate the area contract even if the override compiled; general code relies on what the operation means as well as its signature.

The same approach works with an interface. A chargeAll(List<Chargeable> devices, int minutes) method loops over devices and calls device.charge(minutes). For 20 minutes, the phone starting at 35 percent reaches 75 percent and the scooter starting at 50 percent reaches 70 percent. The loop never selects a charging rule itself.

Let callers choose a list implementation

A parameter List<Shape> accepts both an ArrayList<Shape> and a LinkedList<Shape>. A parameter ArrayList<Shape> rejects the linked list despite needing only list operations. Use the most general type that supplies the required methods; declaring everything as Object would be too general because it lacks area() and list operations.

Make objects sortable with Comparable

Comparable<T> defines an object's natural order. Its compareTo result is negative when this object comes before the other, zero for an ordering tie, and positive when it comes after. The result's sign matters; it need not be exactly −1 or 1.

record Runner(String name, int seconds)
        implements Comparable<Runner> {
    @Override
    public int compareTo(Runner other) {
        return Integer.compare(seconds, other.seconds);
    }
}

A modifiable list with Mia at 3605 s, Ken at 3490 s and Ana at 3720 s becomes Ken, Mia, Ana after Collections.sort(runners). list.sort(null) also uses natural ordering. Build a modifiable list with new ArrayList<>(List.of(...)); attempting to sort the unmodifiable result of List.of(...) throws UnsupportedOperationException.

Use Integer.compare instead of subtracting the values. Subtraction can overflow for large values of opposite signs and return the wrong sign. The same idea applies to Double.compare for decimal fields. In this runner example, equal times tie in ordering even if the names differ, so a comparison tie and object equality need not mean the same thing. Prefer a natural order whose zero result agrees with equality; document an intentional difference.

An enum gives a fixed set of named choices its own type. enum Size { SMALL, MEDIUM, LARGE } allows Size size = Size.MEDIUM;. It prevents a caller from passing the misspelled string "MEDUIM" or the integer 7 to a method that requires Size.

Use names, constants and switch

Each enum constant is a single object, so size == Size.LARGE is a suitable comparison. An enum variable can also be null. Size.values() returns all constants in declaration order; Size.valueOf("LARGE") finds the exact name. The lookup is case-sensitive: "large" causes IllegalArgumentException.

name() returns the declared name. ordinal() returns the zero-based position, so Size.MEDIUM.ordinal() is 1. Inserting a constant changes later positions, so an ordinal is a poor stored code or business value. By default, toString() also returns the name.

A switch expression, standard since Java 14, can return a value:

String label = switch (size) {
    case SMALL -> "S";
    case MEDIUM -> "M";
    case LARGE -> "L";
};

Naming every constant makes the expression exhaustive without a default branch. These cases assume a non-null size; listing the constants does not handle null.

Give each constant meaningful data

enum CupSize {
    SMALL(250), MEDIUM(350), LARGE(500);
    private final int milliliters;
    CupSize(int milliliters) { this.milliliters = milliliters; }
    public int milliliters() { return milliliters; }
}

The semicolon separates the constant list from the members. The constructor runs once for each constant when the enum initializes. It is implicitly private, and callers cannot create new constants with new CupSize(400).

Two large cups and one small cup hold 1250 mL, or 1.25 L. That calculation uses the milliliters field, not the constants' positions. Looping over CupSize.values() and printing each constant and capacity gives "SMALL: 250 mL", "MEDIUM: 350 mL" and "LARGE: 500 mL".

Give constants their own behavior

An enum can implement an interface, and it may give individual constants different method bodies:

enum Operation {
    ADD { int apply(int a, int b) { return a + b; } },
    MULTIPLY { int apply(int a, int b) { return a * b; } };
    abstract int apply(int a, int b);
}

Operation.MULTIPLY.apply(6, 7) returns 42. Each constant completes the abstract operation. Enums implicitly extend java.lang.Enum; they cannot extend another class, and ordinary classes cannot extend them.

Use an enum for options fixed when the program is written, such as directions or order states. A shop's changing list of products belongs in data: adding products should not require rewriting and recompiling an enum declaration.

A record is a concise data class, standard since Java 16. Its header lists the values, called components, that define each instance: record Point(int x, int y) { }.

Use the generated members

The compiler supplies a private final field for each component, a canonical constructor with those components in order, and public accessors named after them. It also supplies equals, hashCode and toString based on the components.

Point a = new Point(3, 4);
Point b = new Point(3, 4);
System.out.println(a.x());
System.out.println(a.equals(b));
System.out.println(a == b);

This prints 3, true and false on separate lines. Matching component values make the records equal, but the two new expressions create separate objects. Equal records have equal hash codes. Their useful generated text includes the record and component names; current JDKs show "Point[x=3, y=4]". That exact text format is not guaranteed, so do not parse it as a data format.

Accessors are x() and y(), not getX() and getY(). A setter that assigns this.x = x does not compile because the component field is final. A method can return a new value instead: Point moveRight(int dx) { return new Point(x + dx, y); }.

Validate in a compact constructor

record Temperature(double celsius) {
    Temperature {
        if (celsius < -273.15) {
            throw new IllegalArgumentException("below absolute zero");
        }
    }
}

A compact constructor repeats the record's name without a parameter list. It checks or normalizes the incoming parameters; Java assigns the component fields after its body. This check rejects −300 °C and accepts 21.5 °C. A text component could be normalized with name = name.trim(); before automatic assignment.

A public record needs a public compact constructor. Records may also declare static fields, static methods and instance methods. An additional constructor delegates to the canonical constructor with this(...). Extra instance fields beyond the components are forbidden.

Protect mutable component objects

Final component fields make immutability shallow. A record holding a mutable list still refers to that list:

record Team(String name, List<String> members) {
    Team {
        members = List.copyOf(members);
    }
}

With java.util.List imported, this stores an unmodifiable copy. Later additions to the original list do not affect the team's membership, and team.members().add("Lee") throws UnsupportedOperationException. The copy protects the list structure; it does not make mutable element objects deeply immutable.

Records implicitly extend java.lang.Record and are final. They cannot extend another class or be extended, but can implement interfaces such as Comparable. Use them for data defined by its values; use an ordinary class for changing state, extra hidden instance fields or an extensible class hierarchy.