Abstract Class vs Interface: When to Use Which?
Abstract class vs interface in Java — when to pick each, shared state vs capability contracts — with a clear code example.
Expected Interview Answer
Use an abstract class when related types share common state and partial implementation you want to reuse, and use an interface when you only need to declare a capability or contract that unrelated classes can implement, since a class can implement many interfaces but extend only one abstract class.
An abstract class can hold instance fields, constructors, and concrete method implementations alongside abstract methods, making it suitable for an is-a hierarchy that shares real state and behavior, such as Animal with a shared name field and a concrete eat() method plus an abstract makeSound(). An interface historically declared only method signatures and constants, and while modern Java allows default and static methods on interfaces, it still cannot hold instance state, and a class can implement any number of interfaces, supporting a can-do capability model like Comparable or Serializable across otherwise unrelated classes. The practical rule of thumb is: pick abstract class for a strong is-a relationship with shared implementation, and interface for a can-do capability that cuts across unrelated class hierarchies, and it is common to use both together, e.g. an abstract base class implementing an interface.
- Abstract classes let you share real state and default logic across a hierarchy
- Interfaces enable multiple capability contracts without inheritance limits
- Choosing correctly avoids forcing unrelated classes into a false hierarchy
- Combining both supports flexible, well-layered designs
AI Mentor Explanation
A base 'Player' abstract class holds shared state every cricketer has — a name, a team, fitness level — plus a concrete method for walking onto the field, while leaving playRole() abstract for batters and bowlers to implement differently. Meanwhile a 'Fieldable' interface can be implemented by any player regardless of their batting/bowling role, since fielding is a capability, not a type of player. That is the split: abstract class for shared player state and is-a hierarchy, interface for a cross-cutting can-do capability like fielding.
Step-by-Step Explanation
Step 1
Check the relationship type
Ask whether the types share a genuine is-a hierarchy (abstract class) or just a common capability (interface).
Step 2
Check for shared state
If related types need shared instance fields or constructors, only an abstract class can hold those.
Step 3
Check for multiple inheritance needs
If a class needs to combine several unrelated capabilities, use interfaces since only one abstract class can be extended.
Step 4
Combine when appropriate
It is common for an abstract class to implement one or more interfaces, giving both shared state and multiple contracts.
What Interviewer Expects
- A clear rule of thumb: is-a with shared state versus can-do capability
- Mention that a class extends only one abstract class but implements many interfaces
- Awareness of modern interface default/static methods and their limits (no instance state)
- A concrete example of using both together
Common Mistakes
- Saying interfaces can never have any method body (ignoring default methods)
- Claiming abstract classes cannot have constructors
- Not mentioning the single-inheritance-of-implementation limitation of abstract classes
- Treating the choice as purely stylistic with no real design implications
Best Answer (HR Friendly)
“I reach for an abstract class when related types genuinely share state and some common implementation, like a base Animal class with a name field and a shared eat method. I reach for an interface when I just need to guarantee a capability, like Comparable or Serializable, that unrelated classes can implement independently. Since a class can only extend one abstract class but implement many interfaces, that constraint often decides it for me too.”
Code Example
abstract class Animal {
protected String name; // shared state, only possible in an abstract class
Animal(String name) { this.name = name; }
void sleep() { System.out.println(name + " is sleeping"); } // shared concrete behavior
abstract void makeSound(); // must be implemented by each subclass
}
interface Trackable { // capability, not an is-a relationship
void reportLocation();
}
class Dog extends Animal implements Trackable {
Dog(String name) { super(name); }
@Override void makeSound() { System.out.println(name + " barks"); }
@Override public void reportLocation() { System.out.println(name + " location sent"); }
}Follow-up Questions
- Can an abstract class implement an interface without providing all method bodies?
- What are default methods in Java interfaces and why were they added?
- Can an interface extend multiple other interfaces?
- What happens if a class implements two interfaces with conflicting default methods?
MCQ Practice
1. A class can extend how many abstract classes directly in Java?
Java supports single class inheritance, so a class can extend only one (abstract or concrete) class.
2. Which of these can only be held by an abstract class, not an interface?
Interfaces cannot hold instance state; abstract classes can have instance fields and constructors.
3. A "can-do" capability shared by unrelated classes is best modeled with?
Interfaces let unrelated classes implement a shared capability without forcing a common ancestry.
Flash Cards
When to use an abstract class? — When related types share genuine state and reusable implementation in an is-a hierarchy.
When to use an interface? — When declaring a can-do capability that unrelated classes can implement.
Key structural limit? — A class extends only one abstract class but can implement many interfaces.
Can interfaces have method bodies? — Yes, via default and static methods, but never instance fields with state.