"Interface" and "abstract class" are two of the most commonly misused OOP terms by non-native English speakers. The vocabulary around them — implements, extends, abstract method, is-a, can-do — has precise meaning in technical discussion.
The core distinction to memorise
Interface = a contract / capability ("can-do"). A class implements an interface. Naming: often ends in -able (Serializable, Comparable, Runnable)
Abstract class = a shared base with partial implementation ("is-a"). A class extends an abstract class.
implements → interface. extends → class (abstract or concrete).
Abstract method = signature only, no body. Concrete method = has a body.
Cannot instantiate an abstract class directly — it must be subclassed.
0 / 5 completed
1 / 5
A Java developer explains a design decision in a code review:
"I used an ___ here because multiple unrelated classes need to implement the same contract — Serializable, Comparable, and Printable. They share no common behaviour, just an obligation."
Which construct best fits this scenario?
Interface — a contract, not an inheritance hierarchy:
This scenario perfectly illustrates the core use case for an interface: multiple unrelated classes need to agree on a set of method signatures, but they share no implementation and have no "is-a" relationship.
Interface (in Java, TypeScript, C#, Go)
Defines a contract — a list of method signatures a class must implement
Contains no implementation (in classic interfaces; modern Java/C# allow default methods, but that's an extension)
A class can implement multiple interfaces — solving the multiple-inheritance problem
Represents a "can-do" / capability relationship: "User implements Serializable" = "a User can be serialised"
Key question: "What can this class do?"
Classic examples:
Comparable — any class that can be compared
Serializable — any class that can be serialised
Runnable — any class that can be run as a thread
Iterable — any class that can be iterated
Abstract class — would be wrong here because:
An abstract class forces a single inheritance hierarchy
User, Order, and Report have no meaningful "is-a" parent relationship
Making them extend a shared abstract class would create artificial coupling
Interview shortcut: "Interface = contract / capability. Abstract class = shared implementation within a hierarchy."
2 / 5
An engineering team is reviewing OOP design for a payment system:
"All payment methods — CreditCardPayment, PayPalPayment, CryptoPayment — share 60% of their logic: validation, logging, and retry handling. Only the actual 40% charge step differs."
Which construct is the better choice to avoid code duplication?
Abstract class — for sharing implementation within a hierarchy:
When a group of closely related classes share a significant amount of implementation code, an abstract class is the right tool. An interface forces each implementor to rewrite the same logic — that's the opposite of DRY.
Abstract class
Can contain concrete methods (with full implementation) alongside abstract methods (signatures only)
Subclasses inherit the concrete methods and are forced to implement the abstract ones
Represents an "is-a" relationship: CreditCardPaymentis aPayment
Key question: "What does this class IS?"
Limitation: a class can only extend one abstract class (single inheritance in Java/C#/TypeScript)
Template Method pattern: the abstract class defines the algorithm skeleton; subclasses fill in the specific steps. This is almost always what people mean when they argue for an abstract class over an interface.
Vocabulary used in code reviews:
"Extract the common logic to an abstract base class."
"The abstract methodexecuteCharge() must be overridden by each payment type."
"Concrete methods like validate() and log() are inherited by all subclasses."
"We should use the Template Method pattern here."
Interface here would be wrong because all three classes would need to duplicate the validation, logging, and retry code — violating DRY and creating maintenance burden.
One of the most important reasons interfaces exist is that many languages (Java, C#, TypeScript) forbid a class from extending more than one abstract/concrete class. Interfaces solve this cleanly.
The problem with multiple inheritance of classes:
If Report tried to extend both LoggableBase and ExportableBase (abstract classes), the compiler would reject it in Java/C#/TypeScript
The famous "Diamond Problem" — ambiguous method resolution when two parent classes define the same method
The solution with interfaces:
A class can implement any number of interfaces: class Report implements Loggable, Exportable, Serializable
Each interface only defines what the class must do, not how — so there is no ambiguity
The class itself provides the implementation for each interface method
Vocabulary for this pattern:
"Reportimplements the Loggable and Exportable interfaces." (verb: implements)
"ReportextendsBaseReport." (verb for class inheritance: extends)
❌ Never say "implements an abstract class" — you extend classes, implement interfaces
❌ Never say "extends an interface" in Java/TypeScript — you implement interfaces (exception: interfaces can extend other interfaces)
"This class doesn't make sense to instantiate directly — a generic Animal object with no species-specific behaviour is meaningless. We should prevent direct instantiation and force developers to use one of the specific subclasses."
Which keyword achieves this in object-oriented languages?
Abstract — the keyword that prevents direct instantiation:
The abstract keyword has two related meanings in OOP, and both are about incompleteness:
abstract class
Cannot be instantiated directly: new Animal() → compile error
Must be subclassed; subclasses provide implementations for abstract methods
Can have both concrete methods (complete implementation) and abstract methods (just a signature)
Common in Java, C#, TypeScript, Python, PHP, Kotlin
abstract method
Has only a signature — no body
Every non-abstract subclass must implement it
In Java: public abstract void makeSound(); — note the semicolon, no braces
In Python: use @abstractmethod decorator from abc module
Why this design matters:
"This is an abstract concept" = you can't have a generic Animal, only a Dog or Cat
The abstract class defines the shape of the hierarchy and enforces the contract on subclasses
It is both a design tool (prevent bad usage) and a communication tool (signals to developers: never instantiate this)
Vocabulary pair:
abstract class / abstract method ↔ concrete class / concrete method
"A concrete class has full implementation and can be instantiated."
"An abstract class is incomplete by design and cannot be instantiated directly."
Common mistake: confusing abstract with private. Private limits visibility; abstract limits instantiation and forces subclass implementation.
5 / 5
A senior engineer explains to a junior developer:
"Think of it this way: an interface answers the question 'What can it do?' An abstract class answers the question 'What is it?'"
Which example best demonstrates the "What is it?" (abstract class) vs "What can it do?" (interface) distinction?
Is-a vs Can-do — the core mental model for interface vs abstract class:
This is the most useful heuristic for choosing between an interface and an abstract class in any language.
"What is it?" → Abstract class (is-a relationship / inheritance hierarchy)
abstract class Shape → Circle, Rectangle, Triangle all are shapes
abstract class Animal → Dog, Cat all are animals
abstract class Payment → CreditCard, PayPal all are payment methods
They share identity, state (fields), and common behaviour (concrete methods)
"What can it do?" → Interface (can-do / capability)
interface Drawable → any class that can be drawn (shapes, icons, charts, maps)
interface Serializable → any class that can be serialised (orders, users, configs)
interface Comparable → any class that can be compared
interface Runnable → any class that can be run as a thread
Notice the naming pattern:
Interface names often end in -able: Serializable, Comparable, Printable, Cloneable, Runnable, Iterable
This "-able" suffix directly signals the "can-do" nature of the contract
Abstract class names are often nouns: Shape, Animal, Vehicle, AbstractRepository
In a real architecture review: "We should model Shape as an abstract class — all shapes share color, area(), and perimeter(). But Drawable should be an interface — we may want to draw things that aren't shapes, like dashboard widgets."