Abstraction in Java — When to Use Abstract Class vs Interface

Q: Abstraction in Java — When to Use Abstract Class vs Interface

**Abstract class** = identity (IS-A), can have instance state, constructors, `protected` methods — single inheritance only. **Interface** = capability (CAN-DO), multiple implementation, Java 8+ `default` methods. Decision rule: need shared instance fields or constructors? → abstract class. Defining a contract any class can fulfill? → interface (modern Java default). Adding a new `abstract` method breaks all subclasses; adding a `default` method to an interface is backward-compatible.

Intermediate·3 min read·

AmazonGoogleMicrosoftTcsInfosys

Fast recall

Quick revision

Core answer

Abstract class = identity (IS-A), can have instance state, constructors, protected methods — single inheritance only. Interface = capability (CAN-DO), multiple implementation, Java 8+ default methods. Decision rule: need shared instance fields or constructors? → abstract class. Defining a contract any class can fulfill? → interface (modern Java default). Adding a new abstract method breaks all subclasses; adding a default method to an interface is backward-compatible.

Interview Answer3 min

Abstraction in Java means hiding the implementation details and exposing only what the caller needs to work with. Java provides two mechanisms for this: interfaces, which define a pure contract with no implementation, and abstract classes, which allow a mix of abstract methods and concrete shared behavior. The distinction between them matters most when designing extensible systems.

Interface — pure contract:

An interface defines what an object can do, not what it is — Comparable, Serializable, Runnable describe capabilities that any class can gain regardless of its inheritance hierarchy
A class can implement many interfaces, which is how Java compensates for the lack of multiple inheritance — behavior composes horizontally through interfaces
Since Java 8, interfaces can carry default method implementations — this was how Collection.stream() was added to millions of existing codebases without breaking anything

Abstract class — shared implementation:

An abstract class makes sense when subclasses share mutable state (instance fields), initialization logic, or non-public helper methods that shouldn't be in an interface
The template method pattern is the canonical use case: the abstract class defines the algorithm skeleton with abstract steps, and subclasses fill in the specific steps
Animal as an abstract class works because Dog and Cat genuinely share name, age, and common behavior — it's an IS-A identity, not just a capability

The Java 8 shift:

Before Java 8, "do I need a method implementation?" was the deciding question — that answer always pointed to abstract classes
After Java 8, the real question is: do you need shared state (instance fields) or constructors? Only abstract classes can have those; interfaces can now have method bodies
Adding a new default method to an interface is backward-compatible; adding a new abstract method to an abstract class immediately breaks every existing subclass

I recommend interfaces as the default in modern Java; reach for abstract classes only when you genuinely need shared mutable state or constructor logic that subclasses must run.

Interview-ready guide

Interview answer

Interface — pure contract:

An interface defines what an object can do, not what it is — Comparable, Serializable, Runnable describe capabilities that any class can gain regardless of its inheritance hierarchy
A class can implement many interfaces, which is how Java compensates for the lack of multiple inheritance — behavior composes horizontally through interfaces
Since Java 8, interfaces can carry default method implementations — this was how Collection.stream() was added to millions of existing codebases without breaking anything

Abstract class — shared implementation:

An abstract class makes sense when subclasses share mutable state (instance fields), initialization logic, or non-public helper methods that shouldn't be in an interface
The template method pattern is the canonical use case: the abstract class defines the algorithm skeleton with abstract steps, and subclasses fill in the specific steps
Animal as an abstract class works because Dog and Cat genuinely share name, age, and common behavior — it's an IS-A identity, not just a capability

The Java 8 shift:

Before Java 8, "do I need a method implementation?" was the deciding question — that answer always pointed to abstract classes
After Java 8, the real question is: do you need shared state (instance fields) or constructors? Only abstract classes can have those; interfaces can now have method bodies
Adding a new default method to an interface is backward-compatible; adding a new abstract method to an abstract class immediately breaks every existing subclass

I recommend interfaces as the default in modern Java; reach for abstract classes only when you genuinely need shared mutable state or constructor logic that subclasses must run.

03 · Deep dive