"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 / 22 completed
1 / 22
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 / 22
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 / 22
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."
6 / 22
A developer is preparing a pull request for a new microservice designed to handle user authentication. They've created an abstract class called `AbstractUser` that defines common properties like `userId`, `email`, and `passwordHash`. Several concrete classes, such as `LocalUser` and `OAuthUser`, inherit from this abstract class but implement different authentication methods (local database vs. third-party provider). During a code review, another developer asks, "Why did you create an abstract class here? Wouldn't an interface be more flexible?" Which of the following best describes the justification for using an abstract class in this scenario?
— The authentication process is inherently complex and requires a rigid structure.
The correct answer highlights the core purpose of an abstract class: providing a common base structure and shared properties.
An abstract class allows subclasses to inherit these commonalities while still implementing specific behavior related to their authentication method – LocalUser will handle local database access, OAuthUser will handle third-party provider integration. Interfaces, conversely, enforce a strict contract for *what* can be done, without providing any implementation details; this would have forced all user types to implement the same authentication logic, which is not appropriate given the differing requirements. Using an abstract class promotes flexibility and allows for more nuanced design.
7 / 22
A team is designing a system for handling different types of vehicles. They decide to use an abstract class `Vehicle` with properties like `speed` and `fuelCapacity`. Concrete classes such as `Car`, `Truck`, and `Motorcycle` inherit from `Vehicle` and implement specific behaviors like `accelerate()`, `brake()`, and `turn()`. During a discussion, one developer suggests using interfaces for each vehicle type. Another developer argues that the abstract class is better because it provides a common base with shared properties and methods that all vehicles should have, regardless of their specific implementation. Which statement best captures the reasoning behind this preference?
Option A: Interfaces are always superior to abstract classes when dealing with polymorphism, ensuring maximum flexibility.
The core reason for choosing an abstract class here is about maintaining a shared blueprint. An abstract class provides a common base with properties and methods that *all* vehicles should have (speed, fuelCapacity, accelerate), regardless of their specific implementation. This avoids code duplication and ensures consistency across the vehicle hierarchy. Option A misrepresents the trade-offs between interfaces and abstract classes; flexibility isn't always guaranteed by an interface.
8 / 22
A team is developing a software architecture for an e-commerce platform. They've identified several key entities: `Product`, `Order`, and `Payment`. Initially, they considered using interfaces to define contracts between these entities but ultimately decided on abstract classes for `Product` and `Payment`.
During a standup update, the lead architect explained: 'We're using abstract classes for `Product` because it naturally represents different *types* of products – Books, Electronics, Clothing – each with inherent properties like ISBN, dimensions, and material. Similarly, the `Payment` class is an abstract base for CreditCardPayment, PayPalPayment, and other payment methods, allowing us to enforce common validation logic regardless of the specific payment processor.'
Which best describes the *primary* reason for this design choice?
The correct answer highlights the key benefit of using abstract classes: encapsulation of shared characteristics. The architect's explanation – focusing on 'types' of products and common validation logic for payments – demonstrates how the abstract class provides a solid foundation while still allowing for specialization. Incorrect options incorrectly frame the flexibility argument (interfaces are *always* more flexible) or overemphasize potential downsides of abstract classes.
9 / 22
A developer is preparing a pull request for a new microservice designed to handle user authentication. They've created an abstract class called `AbstractUser` that defines common properties like `userId`, `email`, and `passwordHash`. Several concrete classes, such as `LocalUser` and `OAuthUser`, inherit from this abstract class but implement different authentication methods (local database vs. third-party provider). During a code review, another developer asks, "Why did you create an abstract class here? Wouldn't an interface be more flexible?" Which of the following best describes the justification for using an abstract class in this scenario?
— The authentication process is inherently complex and requires a rigid structure.
The correct answer highlights the core purpose of an abstract class: providing a common base structure and shared properties.
An abstract class allows subclasses to inherit these commonalities while still implementing specific behavior related to their authentication method – LocalUser will handle local database access, OAuthUser will handle third-party provider integration. Interfaces, conversely, enforce a strict contract for *what* can be done, without providing any implementation details; this would have forced all user types to implement the same authentication logic, which is not appropriate given the differing requirements. Using an abstract class promotes flexibility and allows for more nuanced design.
10 / 22
A team is designing a system for handling different types of vehicles. They decide to use an abstract class `Vehicle` with properties like `speed` and `fuelCapacity`. Concrete classes such as `Car`, `Truck`, and `Motorcycle` inherit from `Vehicle` and implement specific behaviors like `accelerate()`, `brake()`, and `turn()`. During a discussion, one developer suggests using interfaces for each vehicle type. Another developer argues that the abstract class is better because it provides a common base with shared properties and methods that all vehicles should have, regardless of their specific implementation. Which statement best captures the reasoning behind this preference?
Option A: Interfaces are always superior to abstract classes when dealing with polymorphism, ensuring maximum flexibility.
The core reason for choosing an abstract class here is about maintaining a shared blueprint. An abstract class provides a common base with properties and methods that *all* vehicles should have (speed, fuelCapacity, accelerate), regardless of their specific implementation. This avoids code duplication and ensures consistency across the vehicle hierarchy. Option A misrepresents the trade-offs between interfaces and abstract classes; flexibility isn't always guaranteed by an interface.
11 / 22
A team is developing a software architecture for an e-commerce platform. They've identified several key entities: `Product`, `Order`, and `Payment`. Initially, they considered using interfaces to define contracts between these entities but ultimately decided on abstract classes for `Product` and `Payment`.
During a standup update, the lead architect explained: 'We're using abstract classes for `Product` because it naturally represents different *types* of products – Books, Electronics, Clothing – each with inherent properties like ISBN, dimensions, and material. Similarly, the `Payment` class is an abstract base for CreditCardPayment, PayPalPayment, and other payment methods, allowing us to enforce common validation logic regardless of the specific payment processor.'
Which best describes the *primary* reason for this design choice?
The correct answer highlights the key benefit of using abstract classes: encapsulation of shared characteristics. The architect's explanation – focusing on 'types' of products and common validation logic for payments – demonstrates how the abstract class provides a solid foundation while still allowing for specialization. Incorrect options incorrectly frame the flexibility argument (interfaces are *always* more flexible) or overemphasize potential downsides of abstract classes.
12 / 22
A developer is preparing a pull request for a new microservice designed to handle user authentication. They've created an abstract class called `AbstractUser` that defines common properties like `userId`, `email`, and `passwordHash`. Several concrete classes, such as `LocalUser` and `OAuthUser`, inherit from this abstract class but implement different authentication methods (local database vs. third-party provider). During a code review, another developer asks, "Why did you create an abstract class here? Wouldn't an interface be more flexible?" Which of the following best describes the justification for using an abstract class in this scenario?
— The authentication process is inherently complex and requires a rigid structure.
The correct answer highlights the core purpose of an abstract class: providing a common base structure and shared properties.
An abstract class allows subclasses to inherit these commonalities while still implementing specific behavior related to their authentication method – LocalUser will handle local database access, OAuthUser will handle third-party provider integration. Interfaces, conversely, enforce a strict contract for *what* can be done, without providing any implementation details; this would have forced all user types to implement the same authentication logic, which is not appropriate given the differing requirements. Using an abstract class promotes flexibility and allows for more nuanced design.
13 / 22
A team is designing a system for handling different types of vehicles. They decide to use an abstract class `Vehicle` with properties like `speed` and `fuelCapacity`. Concrete classes such as `Car`, `Truck`, and `Motorcycle` inherit from `Vehicle` and implement specific behaviors like `accelerate()`, `brake()`, and `turn()`. During a discussion, one developer suggests using interfaces for each vehicle type. Another developer argues that the abstract class is better because it provides a common base with shared properties and methods that all vehicles should have, regardless of their specific implementation. Which statement best captures the reasoning behind this preference?
Option A: Interfaces are always superior to abstract classes when dealing with polymorphism, ensuring maximum flexibility.
The core reason for choosing an abstract class here is about maintaining a shared blueprint. An abstract class provides a common base with properties and methods that *all* vehicles should have (speed, fuelCapacity, accelerate), regardless of their specific implementation. This avoids code duplication and ensures consistency across the vehicle hierarchy. Option A misrepresents the trade-offs between interfaces and abstract classes; flexibility isn't always guaranteed by an interface.
14 / 22
A team is developing a software architecture for an e-commerce platform. They've identified several key entities: `Product`, `Order`, and `Payment`. Initially, they considered using interfaces to define contracts between these entities but ultimately decided on abstract classes for `Product` and `Payment`.
During a standup update, the lead architect explained: 'We're using abstract classes for `Product` because it naturally represents different *types* of products – Books, Electronics, Clothing – each with inherent properties like ISBN, dimensions, and material. Similarly, the `Payment` class is an abstract base for CreditCardPayment, PayPalPayment, and other payment methods, allowing us to enforce common validation logic regardless of the specific payment processor.'
Which best describes the *primary* reason for this design choice?
The correct answer highlights the key benefit of using abstract classes: encapsulation of shared characteristics. The architect's explanation – focusing on 'types' of products and common validation logic for payments – demonstrates how the abstract class provides a solid foundation while still allowing for specialization. Incorrect options incorrectly frame the flexibility argument (interfaces are *always* more flexible) or overemphasize potential downsides of abstract classes.
15 / 22
A developer is preparing a pull request for a new microservice designed to handle user authentication. They've created an abstract class called `AbstractUser` that defines common properties like `userId`, `email`, and `passwordHash`. Several concrete classes, such as `LocalUser` and `OAuthUser`, inherit from this abstract class but implement different authentication methods (local database vs. third-party provider). During a code review, another developer asks, "Why did you create an abstract class here? Wouldn't an interface be more flexible?" Which of the following best describes the justification for using an abstract class in this scenario?
— The authentication process is inherently complex and requires a rigid structure.
The correct answer highlights the core purpose of an abstract class: providing a common base structure and shared properties.
An abstract class allows subclasses to inherit these commonalities while still implementing specific behavior related to their authentication method – LocalUser will handle local database access, OAuthUser will handle third-party provider integration. Interfaces, conversely, enforce a strict contract for *what* can be done, without providing any implementation details; this would have forced all user types to implement the same authentication logic, which is not appropriate given the differing requirements. Using an abstract class promotes flexibility and allows for more nuanced design.
16 / 22
A team is designing a system for handling different types of vehicles. They decide to use an abstract class `Vehicle` with properties like `speed` and `fuelCapacity`. Concrete classes such as `Car`, `Truck`, and `Motorcycle` inherit from `Vehicle` and implement specific behaviors like `accelerate()`, `brake()`, and `turn()`. During a discussion, one developer suggests using interfaces for each vehicle type. Another developer argues that the abstract class is better because it provides a common base with shared properties and methods that all vehicles should have, regardless of their specific implementation. Which statement best captures the reasoning behind this preference?
Option A: Interfaces are always superior to abstract classes when dealing with polymorphism, ensuring maximum flexibility.
The core reason for choosing an abstract class here is about maintaining a shared blueprint. An abstract class provides a common base with properties and methods that *all* vehicles should have (speed, fuelCapacity, accelerate), regardless of their specific implementation. This avoids code duplication and ensures consistency across the vehicle hierarchy. Option A misrepresents the trade-offs between interfaces and abstract classes; flexibility isn't always guaranteed by an interface.
17 / 22
A team is developing a software architecture for an e-commerce platform. They've identified several key entities: `Product`, `Order`, and `Payment`. Initially, they considered using interfaces to define contracts between these entities but ultimately decided on abstract classes for `Product` and `Payment`.
During a standup update, the lead architect explained: 'We're using abstract classes for `Product` because it naturally represents different *types* of products – Books, Electronics, Clothing – each with inherent properties like ISBN, dimensions, and material. Similarly, the `Payment` class is an abstract base for CreditCardPayment, PayPalPayment, and other payment methods, allowing us to enforce common validation logic regardless of the specific payment processor.'
Which best describes the *primary* reason for this design choice?
The correct answer highlights the key benefit of using abstract classes: encapsulation of shared characteristics. The architect's explanation – focusing on 'types' of products and common validation logic for payments – demonstrates how the abstract class provides a solid foundation while still allowing for specialization. Incorrect options incorrectly frame the flexibility argument (interfaces are *always* more flexible) or overemphasize potential downsides of abstract classes.
18 / 22
Reviewer Alex comments on the PR: 'This `User` class is abstract and doesn't have an implementation for `validateCredentials()`. It's a placeholder – we need to define what validation actually *means* here. It should be concrete, not abstract.' Considering this feedback, which statement best describes Alex's concern regarding the design?
interface User {
validateCredentials(): void;
}
Alex's comment highlights a critical misunderstanding: an abstract class *must* provide a concrete implementation for its methods. An interface defines *what* can be done, not *how*. The `validateCredentials()` method requires specific logic to validate user credentials, which is the responsibility of a concrete class implementing the `User` interface. Therefore, Alex's concern is about the lack of an actual validation function.
19 / 22
During a team discussion in Slack, Sarah asks: 'I'm struggling to understand when to use an interface versus an abstract class. Can someone explain the key difference in terms of defining requirements?' Which response best addresses her question?
//Sarah's Slack Message
Sarah's question focuses on the core distinction. An interface defines a contract that concrete classes *must* fulfill (implementation), while an abstract class provides a partial implementation and can be extended. Options 1 and 3 accurately capture this difference, whereas options 3 and 4 are too general or suggest interchangeable use.
20 / 22
The following API response describes a service that manages user accounts:
{
"status": "success",
"data": {
"user": {
"userId": "12345",
"email": "john.doe@example.com",
"roles": ["admin", "developer"]
}
}
}
Considering this response, which statement best describes the role of an abstract class in designing a system to manage user accounts?
//API Response
The API response shows a basic user object with common fields. An abstract class is typically used as a template or blueprint to define the structure of these base objects. Subclasses (like AdminUser or DeveloperUser) would then inherit from this abstract class and provide specialized behavior or additional properties based on their specific roles.
21 / 22
You're writing a PR description for a new microservice that handles user authentication. You've created an abstract class called `AbstractUser` with properties like `userId`, `email`, and `password`. Which sentence is the MOST appropriate to include in your PR description regarding this abstract class?
//PR Description Draft
Option 2 accurately describes the purpose of an abstract class as a blueprint or template. It clarifies that concrete subclasses will inherit from it and extend its functionality. The other options focus on implementation details (authentication logic) or misinterpretations of abstraction (preventing instantiation).
22 / 22
During the daily stand-up meeting, David says: 'I'm working on an abstract class called `BaseVehicle` that defines common properties like `speed` and `fuelCapacity`. This allows us to easily create concrete classes for different vehicles like Cars and Trucks.' Which statement best reflects David's approach to object-oriented design?
//David's Standup Comment
David's approach demonstrates an understanding of abstraction. The `BaseVehicle` class provides a common interface (speed and fuelCapacity) while allowing for concrete subclasses (Car, Truck) to implement specific vehicle behaviors without modifying the base class. This aligns with the Open/Closed Principle – open for extension but closed for modification.
What does the "Interface vs Abstract Class — OOP Vocabulary Exercises | English for IT" exercise cover?
5 exercises on the precise English vocabulary for OOP design decisions: when to use an interface vs an abstract class, is-a vs can-do, implements vs extends, abstract vs concrete.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "Interface vs Abstract Class — OOP Vocabulary Exercises | English for IT"?
This exercise has 22 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more False Friends & Tricky Words exercises?
Browse the full False Friends & Tricky Words hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.