Interfaces and Abstract Classes

Why this matters

• This is the most frequently asked design question in Java interviews, and default methods in Java 8 changed the correct answer.
• Choosing wrongly shows up later as a class that cannot extend the thing it needs to, because its one extends slot is already taken.
• Every modern Java API — streams, collections, Spring, JDBC — is defined in interfaces, so reading those APIs requires fluency here.

Interfaces

An interface is a contract. Before Java 8 it could hold nothing but abstract method signatures and constants; three releases have since widened it.

public interface Repository<T, ID> {

    // Abstract: implicitly public abstract
    Optional<T> findById(ID id);
    List<T> findAll();
    void save(T entity);

    // Default: a body, inheritable and overridable — added in Java 8
    default boolean existsById(ID id) {
        return findById(id).isPresent();
    }

    // Static: a utility bound to the interface, not inherited — added in Java 8
    static <T, ID> Repository<T, ID> empty() {
        return new EmptyRepository<>();
    }

    // Private: shared helper for default methods, hidden from implementers — added in Java 9
    private void auditLookup(ID id) { }

    // Constant: implicitly public static final
    int MAX_BATCH_SIZE = 500;
}

Abstract classes

An abstract class cannot be instantiated and may mix finished and unfinished methods. Crucially, it can hold state and a constructor.

public abstract class Shape {
    private final String name;          // real instance state

    protected Shape(String name) {      // constructor, called via super()
        this.name = name;
    }

    public abstract double area();       // subclasses must supply this

    public String describe() {          // shared, concrete behaviour
        return name + " with area " + String.format("%.2f", area());
    }
}

public class Circle extends Shape {
    private final double radius;

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

    @Override
    public double area() {
        return Math.PI * radius * radius;
    }
}

Note what describe() does: it calls the abstract area(). The parent defines the algorithm and the child supplies one step. That is the template method pattern, and it is the clearest reason to prefer an abstract class.

Choosing between them

Both together is a common and good pattern: a public interface for callers, plus an abstract skeleton implementation for implementers. The JDK does this throughout — List with AbstractList, Map with AbstractMap.

When two interfaces collide

Default methods reintroduced a limited diamond, and the language forces you to resolve it.

interface Flyer {
    default String move() { return "flying"; }
}

interface Swimmer {
    default String move() { return "swimming"; }
}

class Duck implements Flyer, Swimmer {
    @Override
    public String move() {
        return Flyer.super.move() + " and " + Swimmer.super.move();
    }
}

Without the override this would not compile. The Interface.super.method() syntax is the only way to name a specific inherited default.

Functional interfaces

An interface with exactly one abstract method can be implemented by a lambda. default and static methods do not count towards the one.

@FunctionalInterface
public interface Validator<T> {
    boolean test(T value);                 // the single abstract method

    default Validator<T> and(Validator<T> other) {
        return value -> test(value) && other.test(value);
    }
}

Validator<String> notBlank = text -> !text.isBlank();
Validator<String> shortEnough = text -> text.length() <= 50;

Validator<String> rule = notBlank.and(shortEnough);
System.out.println(rule.test("Core Java"));    // true

The @FunctionalInterface annotation is optional but worth adding: it makes the compiler reject a second abstract method, protecting every lambda that depends on the shape.

Marker interfaces and annotations

A marker interface has no members and exists purely to tag a type — Serializable and Cloneable are the well-known examples. Code then tests the tag with instanceof.

Annotations largely replaced them, because an annotation can carry parameters and apply to methods and fields as well as types.

@Deprecated(since = "3.2", forRemoval = true)
public void oldApi() { }

@FunctionalInterface
public interface Transformer<T, R> {
    R apply(T input);
}

Common misreadings

• "Interfaces cannot have method bodies." They can, since Java 8: default and static, plus private helpers since Java 9.
• "Abstract classes must contain abstract methods." They need not. Declaring a class abstract only prevents instantiation.
• "Interface fields are instance state." They are public static final constants, shared and unmodifiable.
• "An abstract class cannot have a constructor." It must, and subclasses call it through super().
• "Interfaces are always the right default." When you need shared state, only an abstract class works.
• "default methods brought multiple inheritance of state." They brought behaviour only. Instance fields are still single-inheritance.