When do you choose an abstract class over an interface?

The Answer

• The textbook answer — "an interface has no implementation" — has been wrong since Java 8. Interfaces have default methods, static methods, and Java 9+private methods.
• What is left is short. An abstract class can have instance state and a constructor; an interface can have neither. An interface's fields are always public static final.
• And you can extend one class but implement many interfaces. That is the constraint that usually decides it.
• Choose an abstract class when subtypes must share mutable state, or when construction has an invariant every subtype must run through.
• Choose an interface for a capability, for anything that might be mixed into an unrelated hierarchy, and as the default for a public API.
• Inheriting two conflicting defaults is a compile error you must resolve with Interface.super.method(). But a class implementation always wins over an interface default, silently.

Understand It

What an interface can do now

Every Java 8 and 9 addition in one declaration, all of it running:

Auditable simple = Auditable.of("ORD-9");

System.out.println("constant            : " + Auditable.CHANNEL);
System.out.println("static factory gave : " + simple.id());
System.out.println("default + private   : " + simple.summary());
System.out.println("it is a lambda      : " + Auditable.class.isInterface());

constant            : audit
static factory gave : ORD-9
default + private   : [audit] ORD-9
it is a lambda      : true

summary() is a default method that calls prefix(), a private interface method. The implementation is a lambda — one abstract method, so Auditable is a functional interface — and it still inherits behaviour it never declared.

So "interfaces are just contracts" is out of date by more than a decade. The question is what genuinely remains.

The two differences that actually remain

State. An abstract class can have instance fields, and they can be mutable and protected. An interface cannot have instance fields at all — every field is implicitly public static final, whether you write the modifiers or not:

Field channel = Auditable.class.getDeclaredField("CHANNEL");
int m = channel.getModifiers();

System.out.println("declared as just `String CHANNEL = \"audit\";`");
System.out.println("  public : " + Modifier.isPublic(m));
System.out.println("  static : " + Modifier.isStatic(m));
System.out.println("  final  : " + Modifier.isFinal(m));

declared as just `String CHANNEL = "audit";`
  public : true
  static : true
  final  : true

Try to assign to one and the compiler tells you exactly what it is:

error: cannot assign a value to static final variable count

A default method therefore has no per-instance state to work with. It can only call other methods on the interface. That is the hard limit, and it is why default methods are good at deriving things and bad at holding them.

Construction. An abstract class has a constructor, which runs before any subclass body, so it can enforce an invariant every subtype must pass through. An interface has no constructor, so it cannot.

Invoice invoice = new Invoice("anita");
System.out.println("state set by the abstract constructor : " + invoice.summary());

state set by the abstract constructor : owned by anita

Those two — state and construction — are the whole list. Everything else you may have learned as a difference either went away in Java 8 or was never true.

The class always wins, and it does so silently

Invoice extends Document, which has a concrete summary(), and it also implements Timestamped, which has a default summary(). Two inherited implementations, one signature, and it compiled without complaint. The output above shows which one ran: the class's.

This is a real rule with a name — the class always wins — and it exists so that adding a default method to an interface can never change the behaviour of an existing class that already had that method. That is the guarantee that let the JDK add forEach to Iterable without breaking the world.

It is also a trap. Adding Timestamped to a class that already has summary() looks like it does something and does nothing, with no warning. If you meant the interface's version, you have to say so explicitly.

The diamond is a compile error, on purpose

Two interfaces with the same default and no class implementation is the case Java refuses to guess about:

interface A { default String hello() { return "A"; } }
interface B { default String hello() { return "B"; } }

class C implements A, B { }

error: types A and B are incompatible;
  class C inherits unrelated defaults for hello() from types A and B

You must resolve it, and the syntax for reaching a specific super-interface is Interface.super.method():

System.out.println(new Receipt().summary());

[audit] ORD-1 / at 09:00

This is the answer to "does Java have multiple inheritance?" and it is worth being precise: Java has multiple inheritance of behaviour, but not of state. Receipt inherits two implementations of summary(). What it cannot inherit is two sets of fields — which is the half that caused C++'s diamond problem in the first place. Removing state from the picture is what made multiple inheritance of behaviour safe enough to add.

Why default methods exist at all

This is the "why" that separates a memorised answer from an understood one. default methods were not added to make interfaces more convenient. They were added to solve a library evolution problem.

Before Java 8, adding a method to a published interface was a breaking change: every implementation in every codebase stopped compiling. So the JDK could not add stream() to Collection, and libraries shipped an AbstractXxx adapter class next to each interface so implementors had somewhere safe to inherit from.

default methods removed that constraint. Collection.stream(), Iterable.forEach, Comparator.reversed(), Map.getOrDefault — all added to interfaces that thousands of classes already implemented, none of them breaking. Knowing this reframes the design guidance: a default method is best understood as a migration tool and a convenience derived from the abstract methods, not as a place to put your real logic.

Reference

The comparison, current as of Java 21

Choosing, as a sequence of questions

1. Do subtypes need to SHARE MUTABLE STATE?
   yes -> abstract class. An interface cannot hold it.

2. Does construction have an invariant every subtype must run?
   yes -> abstract class. An interface has no constructor.

3. Might an implementor already extend something else?
   yes -> interface. You only get one superclass, and taking it is
          a decision you make on the implementor's behalf.

4. Is this a CAPABILITY rather than an IS-A?
   Comparable, Closeable, Serializable — these are things a type can DO.
   -> interface.

5. Still unsure?
   -> interface. It is the less constraining choice, it can be a lambda
      target, and you can always add an abstract base class beside it.

Point 5 is the practical default and the JDK follows it: List is the interface, AbstractList is the convenience beside it, and implementors choose. You are not obliged to pick one.

Both, which is usually the right answer for a library

// The contract everyone codes against.
public interface Repository<T, ID> {
    Optional<T> findById(ID id);
    List<T> findAll();

    // Derived from the abstract methods — safe as a default, because it
    // needs no state of its own.
    default boolean exists(ID id) {
        return findById(id).isPresent();
    }
}

// The convenience for implementors who want it, holding the shared state
// a default method cannot.
public abstract class AbstractCachingRepository<T, ID> implements Repository<T, ID> {
    private final Map<ID, T> cache = new ConcurrentHashMap<>();   // state

    protected AbstractCachingRepository(int warmupSize) {          // constructor
        // an invariant every subtype passes through
    }

    @Override
    public Optional<T> findById(ID id) {
        return Optional.ofNullable(cache.computeIfAbsent(id, this::load));
    }

    protected abstract T load(ID id);
}

The traps, each in one line

// 1. The class always wins — silently. This compiles and prints the CLASS's
//    version, even though you just added the interface for its default.
class Invoice extends Document implements Timestamped { }

// 2. A default method cannot override anything from Object. equals, hashCode
//    and toString are all rejected, because the class always wins anyway and
//    a default could never be reached.
interface Bad { default String toString() { return "x"; } }
// error: default method toString in interface Bad overrides a member of java.lang.Object

// 3. An interface field is shared, not per-instance. This is one counter for
//    the whole program, and it is final, so you cannot even increment it.
interface Counted { int count = 0; }

// 4. Adding an abstract method to a published interface still breaks every
//    implementor. Only DEFAULT methods are safe to add.

Scenarios

A framework needs a new method on an interface a hundred teams implement. This is precisely the problem default methods were built for. Ship it with a default that derives a sensible answer from the existing abstract methods, and it is source- and binary-compatible for every implementor. If no sensible default exists, that is real information: the method probably does not belong on this interface, or you are looking at a new interface and a major version.

You want an abstract class so subtypes cannot skip validation. Good instinct, and the abstract class is right if the validation needs constructor-time state. But check the cost first: you are spending the implementor's single extends slot, and if any of them already extends a framework base class they are stuck. The alternative is an interface plus a static factory that performs the validation and returns the implementation — same guarantee, no inheritance spent. Choose the abstract class when subtypes genuinely need the shared fields, not merely the shared check.

Someone adds an interface to a class and nothing changes. They added Timestamped expecting summary() to start returning a timestamp, and the class's own summary() kept winning. No error, no warning, and the code review passed because the diff looked right. Worth knowing as a rule: if you want the interface's default, @Override it and call Timestamped.super.summary(). If you did not want the class's, the class should not have had the method.

Two libraries you do not control both declare default close(). You implement both interfaces and the class will not compile — inheriting unrelated defaults. There is no way to ask for "whichever", and that is correct: the compiler cannot know which semantics you want. You write the override and delegate explicitly, and the two lines you write are documentation of a decision that would otherwise have been made by accident. This is the diamond problem handled rather than avoided.

Interviewer's Next Move

1. "Can an interface have state?" No instance state. Every field in an interface is implicitly public static final, so it is one shared constant, not per-instance data — and you cannot assign to it. That is the main reason abstract classes still exist: a default method has no fields of its own to work with and can only call other interface methods.

2. "What problem do default methods solve, and what did they reintroduce?" They solve library evolution: before Java 8 adding a method to a published interface broke every implementor, which is why Collection.stream() could not exist. They reintroduced multiple inheritance — of behaviour, not state. Inheriting two conflicting defaults is a compile error you resolve with Interface.super.method().

3. "Does Java have multiple inheritance?" Of behaviour, yes, since 8. Of state, no, and that is the distinction that matters: the classic diamond problem is about duplicated fields, and since interfaces cannot hold fields, the hard case cannot arise. What remains is ambiguous behaviour, and Java makes that a compile error rather than guessing.

4. "A class extends a base class with summary() and implements an interface with a default summary(). Which runs?" The class's. The rule is "the class always wins", and it exists so that adding a default to an interface can never change how an existing class behaves — the compatibility guarantee that made default methods possible at all. It compiles with no warning, which makes it a genuine trap when someone adds the interface expecting the default to take effect.

5. "Can a default method override equals or toString?" No — it is a compile error. Every class inherits those from Object, and since the class always wins, a default could never be reached; allowing it would be declaring dead code. It also stops someone weakening the equals contract for every implementor of an interface at once.

Code traps

interface Greeter {
    String name = "default";
    default String greet() { return "hello " + name; }
}

class Person implements Greeter {
    String name = "ravi";
}

System.out.println(new Person().greet());

interface A { default void run() { System.out.println("A"); } }
interface B extends A { default void run() { System.out.println("B"); } }
class C implements A, B { }

new C().run();

Common wrong answers

Check Yourself

Q1. What can an abstract class do that an interface cannot, in one sentence each?

Q2. Why is inheriting two conflicting defaults an error, while a class method silently beating an interface default is not?

Q3. You are designing a public API and genuinely cannot decide. What do you ship?

Practice