Abstract classes & interfaces: interview questions & scenarios

Model answer

Yes. You can't write new PaymentProcessor(...), but every subclass object contains the abstract class's fields, and something has to initialise them. When you call new CardProcessor(), the JVM allocates one object for the whole hierarchy, then runs constructors top-down through super(...): Object(), then the abstract class constructor, then the subclass constructor.

So the constructor is where the abstract class enforces its invariants: required arguments, null checks and default state. If its only constructor takes a String name, every subclass is forced to supply a name.

public abstract class PaymentProcessor {
    private final String name;

    protected PaymentProcessor(String name) {
        this.name = Objects.requireNonNull(name);
    }
}

final class CardProcessor extends PaymentProcessor {
    CardProcessor() { super("card"); }
}

This is the construction order I want you to picture when you explain it.

Fig. 1

The diagram shows one CardProcessor object whose construction runs Object first, then the abstract parent, then the concrete child.

Model answer

abstract means "a subclass will provide the implementation". Each of the other modifiers makes that impossible:

• final forbids overriding, or subclassing when used on a class.
• static methods are hidden, not overridden, so dynamic dispatch cannot reach a subclass version.
• private methods are not inherited, so no subclass can see the method to implement it.

javac reports an illegal combination of modifiers. abstract synchronized and abstract native are rejected too, because both describe an implementation that does not exist.

Model answer

No. Interface methods without a body are implicitly public abstract, so FlatDiscount.apply is package-private and tries to reduce visibility: attempting to assign weaker access privileges; was public. Add public to the implementation.

MAX_DISCOUNT is fine: interface fields are implicitly public static final, so it is a constant shared by everyone, not per-object state.

Model answer

An interface cannot have constructors or instance fields. Its fields are always public static final, so they are constants, not per-object state. Since Java 8 it can have default and static methods; since Java 9 it can have private helper methods used by other interface methods.

The important boundary is instance state. If you need each object to carry data owned by the base type, that points toward an abstract class or composition.

Model answer

It prints channel = null. The Notifier constructor runs before SmsNotifier's field initialisers. The call to channel() still dispatches to SmsNotifier.channel(), because virtual dispatch uses the object's real class even during construction, but the field still holds its zeroed default.

The production fix is to remove the overridable call from the constructor. Pass data up instead: Notifier(String channel) and super("sms"), or do logging after the object is fully built.

Model answer

The difference that still matters is state and identity, not "can it have code". An abstract class can have instance fields, constructors, protected and final methods, and a class can extend only one. An interface has no instance state and no constructors, all non-private members are public, and a class can implement many.

My rule: use an abstract class when related types share state or construction rules that must be enforced in one place, or when you need a final template method. Use an interface for a capability that unrelated classes may have alongside others, like Comparable or AutoCloseable. Often the best design is both: a small interface as the public type plus an optional skeletal abstract class, like List and AbstractList.

Model answer

It does not compile: types Logger and Metrics are incompatible; class Telemetry inherits unrelated defaults for tag(). Neither interface is more specific than the other, so the class must override the method. Inside the override, Interface.super.method() calls a specific parent's default:

interface Logger  { default String tag() { return "log"; } }
interface Metrics { default String tag() { return "metrics"; } }

class Telemetry implements Logger, Metrics {
    @Override public String tag() {
        return Logger.super.tag() + "+" + Metrics.super.tag();
    }
}

The resolution rule is short enough to draw on a whiteboard.

Fig. 1

The diagram shows Java resolving a method by checking class methods first, then the most specific interface default, then requiring an explicit override for unrelated defaults.

Model answer

base to u1
dropped to u2

The class wins. OrderService inherits send from BaseService and a default send from Notifier, and a method from the superclass chain always beats an interface default, even though BaseService has never heard of Notifier.

The second line goes through the static factory. The lambda implements channel(), the only abstract method, and the default send builds "dropped to u2".

Model answer

Serializable is a marker interface: it gives the class a type that library code can check with instanceof. ObjectOutputStream.writeObject throws NotSerializableException when the object graph reaches a non-serializable object, unless that field is marked transient.

A marker interface defines a type, so the compiler can enforce it in method signatures. An annotation can carry values and mark methods, fields or packages, but it does not make cache(Object) refuse the wrong object at compile time. My rule: if you would ever want a parameter of that type, use a marker interface; otherwise, an annotation.

Model answer

Default methods let interfaces evolve without breaking every implementer. That is how the JDK added stream(), forEach(), removeIf() and Map.getOrDefault() with bodies written in terms of existing methods.

The catch is conflicts. Adding a default is binary compatible, so old class files can load, but if a class implements two interfaces that each add default String describe() in separately compiled jars, calling describe() can throw IncompatibleClassChangeError. Recompiling turns it into a compile error and forces the class to override.

Model answer

Use a sealed interface with one record per state. Records are implicitly final, each carries its own data, and a switch over the sealed type is checked for exhaustiveness:

sealed interface PaymentState permits Pending, Authorized, Captured, Failed { }
record Pending(String orderId) implements PaymentState { }
record Authorized(String orderId, BigDecimal amount, String authCode) implements PaymentState { }
record Captured(String orderId, BigDecimal amount) implements PaymentState { }
record Failed(String orderId, String reason) implements PaymentState { }

static String describe(PaymentState s) {
    return switch (s) {
        case Pending p -> "waiting for " + p.orderId();
        case Authorized a -> "authorised " + a.amount();
        case Captured c -> "captured " + c.amount();
        case Failed f -> "failed: " + f.reason();
    };
}

An enum does not fit well, because each constant is a singleton with the same fields; here every state carries different data.

Model answer

It is a useful starting sentence, but it misses the design trade-off. Interfaces are contracts because they define a type that unrelated classes can implement, and Java lets a class implement many. Abstract classes are partial implementations, but they also own construction rules, state, protected hooks and final template methods.

The stronger answer is to talk about API shape. Public APIs usually depend on the interface; shared code can live in a skeletal abstract class for implementations that want it. That gives callers flexibility without forcing every implementer into the same superclass.

Model answer

Someone probably added default -> throw new IllegalStateException() to switches over the sealed type. That default turns off exhaustiveness checking. Without it, adding Refunded makes every incomplete switch a compile error. With it, the code compiles and fails at runtime.

The runtime safety is already there. For an exhaustive switch with no default, javac inserts a hidden fallback that throws MatchException in Java 21 if stale code sees a subtype it did not know about. The JVM also enforces the sealed hierarchy through the PermittedSubclasses attribute at class load.

Model answer

Because it could never run. Every class extends Object, which already has equals, hashCode and toString, and under the class-wins rule any method from the class hierarchy beats an interface default. A default equals would be dead code, so javac rejects it.

An interface can still redeclare these methods as abstract to document a contract; Comparator does that with equals. It cannot supply a body.

Model answer

At the bytecode level, yes in principle; in production, the bigger issue is often lost inlining. A call through a class type is invokevirtual, which reads a fixed vtable slot. A call through an interface type is invokeinterface, where HotSpot may look through the class's itable to find the matching interface method.

The JIT usually removes the difference. A monomorphic call site gets an inline cache and is usually inlined. Bimorphic sites get two checks. Megamorphic sites, often 3 or more receiver classes, stop inlining and use a slower stub. If latency changed after adding implementations, I would inspect receiver type profiles and whether a hot call site became megamorphic.