When would you use an abstract class instead of an interface in Java?
Use an interface to define a contract, what a type can do, without caring how. Use an abstract class when you have shared implementation you want subclasses to inherit, plus some methods you want to force subclasses to implement themselves. Since Java 8, interfaces can have default methods, which narrowed the gap, but the real distinguishing factor hasn’t changed: a class can implement many interfaces but extend only one class (abstract or not), because Java doesn’t support multiple inheritance of state.
The decision in practice
If you’re modeling “can this thing do X” across unrelated classes (like Comparable, Runnable, Serializable), that’s an interface, those classes have nothing in common except the capability. If you’re modeling “these things are fundamentally the same kind of object with some shared state and behavior” (like a PaymentProcessor abstract base class with a shared validateAmount() method and an abstract charge() method each subclass must implement differently), that’s an abstract class.
Best practice
Favor interfaces for public API design since they’re more flexible for callers (any class can implement multiple interfaces), and use abstract classes internally within a package hierarchy where you control all the subclasses and genuinely need to share field state or constructor logic.
Edge case interviewers probe for
Ask about interface default methods and the “diamond problem”: if a class implements two interfaces with conflicting default methods, Java forces you to explicitly override and resolve it. It’s a compile error, not silent ambiguity, unlike some other languages’ multiple inheritance.
Common mistake
Saying “interfaces are 100% abstract and abstract classes can have some implementation” as the entire answer. That was true before Java 8 but is now an incomplete picture: interfaces can have default and static methods too. The real difference is about state (fields, constructors) and single vs. multiple inheritance, not about “can it have a method body.”
What the interviewer is checking
Whether you can reason about design intent (contract vs. shared implementation) instead of reciting syntax rules from memory.
An interface is like a job posting that just lists required skills: “must be able to drive.” A car, a truck, and a golf cart can all satisfy that requirement despite being completely different vehicles that share nothing else in common. That’s what makes interfaces so flexible, any unrelated class can sign up for the same “job.”
An abstract class is more like a template for a specific family. Imagine a “Vehicle” blueprint that already has a fuel tank and a speedometer built in (shared stuff every vehicle needs), but leaves a blank spot labeled “how do you start the engine,” because a car, motorcycle, and truck each start differently. Every subclass gets the shared parts for free and only has to fill in the blank.
The reason you can only extend one abstract class but implement many interfaces: you can only be built from one blueprint (you can’t be a Car-blueprint and a Boat-blueprint at the same time), but you can hold as many separate skill certificates as you want.
Why interviewers ask this
It’s usually one of the first “do you actually understand OOP design, not just syntax” questions in a fresher or early-career Java interview.
What a strong answer signals
That you think about “is-a” relationships and shared state versus “can-do” capabilities when designing classes, not just memorized rules.
Common follow-ups
- Can an interface have a constructor? Why or why not?
- What are default methods and why were they added in Java 8?
- Can an abstract class have zero abstract methods?
Advanced variation
“Design a payment processing system supporting credit cards, UPI, and wallets,” which expects an abstract PaymentMethod base class for shared validation plus a Refundable interface only some payment types implement.
A real e-commerce checkout system used an abstract PaymentProcessor class holding shared logic (amount validation, currency conversion, logging) with an abstract charge() method. CreditCardProcessor, UpiProcessor, and WalletProcessor each extended it and implemented charge() differently. Separately, only CreditCardProcessor and WalletProcessor implemented a Refundable interface, since UPI refunds in that system went through a manual back-office process instead of an API call, a distinction that would have been awkward to express with abstract classes alone.
public abstract class PaymentProcessor {
// Shared state and logic every payment type needs.
protected void validateAmount(double amount) {
if (amount <= 0) throw new IllegalArgumentException("Amount must be positive");
}
// Each payment type must define its own charging logic.
public abstract boolean charge(double amount);
}
interface Refundable {
boolean refund(String transactionId, double amount);
}
public class CreditCardProcessor extends PaymentProcessor implements Refundable {
public boolean charge(double amount) {
validateAmount(amount);
// call card network...
return true;
}
public boolean refund(String transactionId, double amount) {
// call refund API...
return true;
}
}- 1Interfaces define a capability contract; abstract classes share implementation across closely related subclasses.
- 2A class extends only one class (abstract or not) but can implement many interfaces.
- 3Since Java 8, interfaces can have default and static methods, but still cannot hold instance state.
- 4Conflicting default methods from two interfaces force an explicit override, resolved at compile time.
- 5Choose based on design intent: “is-a with shared state” versus “can-do capability,” not just method-body syntax.