Abstract Class vs Interface in Java

An abstract class is a class that cannot be instantiated and exists to be extended. It can hold instance state, it can have a constructor, and it can carry concrete helper methods that subclasses inherit. An interface is a contract: it describes what a type can do, and it can also supply default and static method bodies, but it cannot hold instance state.

That single difference — state — is what everything else follows from. An abstract class can promise that every subclass has a particular field and that it is initialised in the superclass constructor. An interface cannot, because there is nowhere to put an instance field and no constructor to run.

public class Main {
    public static void main(String[] args) {
        // An interface type can hold any implementation.
        Vehicle car = new Car("red");
        Vehicle bike = new Bike("blue");

        System.out.println("car  : " + car.describe() + ", doors=" + car.doors());
        System.out.println("bike : " + bike.describe() + ", doors=" + bike.doors());
    }
}

// An interface defines a contract and may provide default behaviour.
interface Vehicle {
    String describe();

    default int doors() {
        return 4;
    }
}

// An abstract class can hold state and constructor logic.
abstract class BaseVehicle implements Vehicle {
    protected final String colour;

    BaseVehicle(String colour) {
        this.colour = colour;
    }

    @Override
    public String describe() {
        return getClass().getSimpleName() + " in " + colour;
    }
}

class Car extends BaseVehicle {
    Car(String colour) {
        super(colour);
    }
}

class Bike extends BaseVehicle {
    Bike(String colour) {
        super(colour);
    }

    @Override
    public int doors() {
        return 0;
    }
}

The output shows both mechanisms at work. The describe implementation lives in the abstract class and uses the colour field, which only an abstract class could hold. The doors behaviour comes from the interface's default method, and Bike overrides it without the abstract class having to know anything about it.

The other differences to name: an abstract class has one superclass, an interface has many. A class can extend one abstract class and implement several interfaces at the same time. And access modifiers on interface members are implicitly public, whereas an abstract class may use any modifier.

Choose an abstract class when the subtypes share state or implementation. Choose an interface when they share only a contract.

Abstract class first, in these situations. The subclasses need to extend a common set of fields — a base entity with an id and a created timestamp, for instance. The subclasses should share a concrete algorithm that differs only in one step, so the base class implements the template and subclasses fill in the gap. The hierarchy is genuinely a kind-of relationship rather than a role, and you want to forbid the wrong kind of subclass. Or you need to control construction, which an interface simply cannot do.

Interface first, in these situations. The relationship is a role rather than a kind — a class implements Serializable, Comparable or a logging contract without being a subclass of anything in particular. The behaviour is orthogonal to what the type already is, so it belongs in a mixin rather than a base class. You want a type to be able to take on several unrelated roles at once, which a single superclass cannot allow. Or you are publishing an API and want implementors to be free to extend whatever they already extend.

The pragmatic rule used in most teams: define an interface at the boundary you program against, and use an abstract class behind it when you want to share code and state. A common and effective pattern is an interface plus a package-private abstract base class that implements it — the interface is the public contract, the abstract class is the implementation detail that can change without breaking anyone.

Historically an interface could declare only abstract methods and constants. Every implementation had to provide every method itself, which meant that adding a method to a published interface broke every implementor — a famously painful kind of change. The change addressed this in three ways.

Default methods give an interface a method with a body. An implementing class inherits it and may override it. That solves the evolution problem: you can add a method to an interface with a sensible default implementation and existing implementors keep working. It also lets an interface carry a small amount of shared behaviour — a Comparator with a default reversed(), for example.

Static methods belong to the interface itself rather than to its instances. They are the natural home for factory methods and small helpers that conceptually belong with the contract but do not need an instance — a Comparator.comparing helper, or a static validation method used by the abstract methods.

Private methods let a default method share helper code with other default methods in the same interface without exposing it to implementors.

public class Main {
    public static void main(String[] args) {
        Greeter g = new PoliteGreeter();
        System.out.println("greet      : " + g.greet());
        System.out.println("greet twice: " + g.greetTwice());

        // A static interface method is called on the interface, not an instance.
        System.out.println("static     : " + Greeter.version());
    }
}

interface Greeter {
    String greet();

    // A default method: inherited by every implementation.
    default String greetTwice() {
        return greet() + " " + greet();
    }

    // A static interface method belongs to the interface itself.
    static String version() {
        return "Greeter v1";
    }
}

class PoliteGreeter implements Greeter {
    @Override
    public String greet() {
        return "hello";
    }
}

The cost of default methods is that they reintroduce the diamond problem for behaviour. If a class implements two interfaces that both supply a default method with the same signature, the compiler refuses to compile until the class overrides the method and resolves the conflict. The rules are: the most specific method wins, and an abstract method beats a default method.

So the design guidance is: use default methods for genuinely universal behaviour with a sensible default, not as a shortcut for sharing code between unrelated implementations. When the shared code is substantial, an abstract class is still the better home for it.