Abstraction in Java is implemented through two main constructs: abstract classes and interfaces. An abstract class is a class declared with the 'abstract' keyword that may contain both abstract methods (without implementation) and concrete methods (with implementation), and cannot be instantiated directly. An interface is a fully abstract contract (traditionally containing only method signatures) that a class 'implements', specifying a set of behaviors a class must provide without dictating how.
Chapter 13 · Java
Java Interfaces and Abstract Classes
Definition
Simple Explanation
Think of an interface like a job description posted for hiring — it lists required skills and responsibilities (methods) without specifying exactly how each employee will perform them; any candidate (class) that 'signs the contract' (implements the interface) must fulfill every listed responsibility in their own way. An abstract class, on the other hand, is more like a partially-filled employee training manual — some sections are already fully written out (concrete methods everyone follows identically), while other sections are deliberately left blank with just a heading (abstract methods), to be filled in differently by each specific role (subclass) that uses this manual as their base.
Real-Life Example
Consider a payment gateway integration system that needs to support multiple, unrelated payment providers like Stripe, PayPal, and Razorpay. A 'PaymentProcessor' interface defines required methods like 'authorize()', 'capture()', and 'refund()' that every payment provider's class must implement, without dictating HOW each provider's specific API calls work internally. Meanwhile, if there's shared logic across several related shape classes in a graphics application — like all shapes needing a 'color' field and a common 'displayColor()' method, but each needing its own unique 'calculateArea()' formula — an abstract 'Shape' class is more appropriate, since it can provide the shared, concrete 'displayColor()' implementation once, while leaving 'calculateArea()' abstract for each specific shape subclass to define individually.
Why We Need It
As systems grow, different parts of a codebase (or even different developer teams) need to reliably work with objects whose EXACT implementation details may vary or aren't known upfront, while still relying on a guaranteed set of available behaviors (a 'contract'). Abstraction through interfaces and abstract classes allows developers to write code against these high-level contracts rather than specific concrete implementations, making systems more flexible, decoupled, and extensible — new implementations (like adding a new payment provider) can be introduced later with zero changes required to the existing code that already depends on the interface or abstract class.
Types
- Abstract Class with Abstract and Concrete Methods: A class declared with 'abstract' that can mix fully-implemented (concrete) methods, shared fields, and constructors, alongside abstract methods that subclasses are required to implement themselves.
- Pure Interface (Traditional): Prior to Java 8, an interface could only contain abstract method signatures (implicitly public and abstract) and constant fields (implicitly public, static, and final), with absolutely no method implementations allowed.
- Interface with Default and Static Methods (Java 8+): Modern Java interfaces can include 'default' methods (providing a default implementation that implementing classes can optionally override) and 'static' methods (utility methods callable directly on the interface itself, not requiring an implementing object).
- Functional Interface: An interface containing exactly one abstract method, often annotated with '@FunctionalInterface', designed specifically to be implemented concisely using a lambda expression, forming the foundation of Java's functional programming features.
Syntax
// Abstract class:
abstract class ClassName {
abstract returnType methodName();
// concrete methods and fields also allowed
}
// Interface:
interface InterfaceName {
returnType methodName();
default returnType defaultMethod() { /* implementation */ }
}
class Implementer implements InterfaceName {
public returnType methodName() { /* required implementation */ }
}
Problem Statement
A beginner wants to design a media player application with a 'Playable' interface defining a required 'play()' method that any media type (Song, Video, Podcast) must implement, and separately, an abstract 'Shape' class that provides a shared 'displayInfo()' method while leaving 'calculateArea()' abstract for each specific shape to implement.
Code Examples
Interface Implementation Across Unrelated Classes
This example defines a 'Playable' interface with a required 'play()' method, implemented by two otherwise unrelated classes, Song and Podcast, demonstrating how interfaces establish a behavioral contract across diverse types.
interface Playable {
void play();
}
class Song implements Playable {
@Override
public void play() {
System.out.println("Playing song with audio streaming...");
}
}
class Podcast implements Playable {
@Override
public void play() {
System.out.println("Playing podcast episode with chapter markers...");
}
}
public class InterfaceDemo {
public static void main(String[] args) {
Playable[] mediaItems = { new Song(), new Podcast() };
for (Playable item : mediaItems) {
item.play();
}
}
}
Playing song with audio streaming...
Playing podcast episode with chapter markers...
'interface Playable' declares an abstract method 'play()' with no implementation, acting purely as a contract. Both 'Song' and 'Podcast' use 'implements Playable' and MUST provide their own concrete implementation of 'play()', or the code would fail to compile. Even though Song and Podcast share no inheritance relationship with each other at all (they don't extend a common class), they can both be treated uniformly through the shared 'Playable' interface type, demonstrating how interfaces enable polymorphism across otherwise unrelated classes.
Abstract Class with Shared Concrete Logic and an Abstract Method
This example creates an abstract 'Shape' class with a concrete, shared 'displayInfo()' method and an abstract 'calculateArea()' method, which the 'Circle' subclass must implement.
abstract class Shape {
String color;
public Shape(String color) {
this.color = color;
}
public void displayInfo() {
System.out.println("This is a " + color + " shape with area: " + calculateArea());
}
abstract double calculateArea();
}
class Circle extends Shape {
double radius;
public Circle(String color, double radius) {
super(color);
this.radius = radius;
}
@Override
double calculateArea() {
return Math.PI * radius * radius;
}
}
public class AbstractClassDemo {
public static void main(String[] args) {
Circle circle = new Circle("Blue", 3.0);
circle.displayInfo();
}
}
This is a Blue shape with area: 28.274333882308138
'Shape' is declared 'abstract', meaning it can never be instantiated directly (e.g., 'new Shape("Red")' would cause a compile error). It provides a fully working, concrete 'displayInfo()' method shared by all subclasses, which internally calls the abstract 'calculateArea()' method — notice this concrete method can call an abstract one, and at runtime, it correctly invokes whichever subclass's specific implementation is actually present (here, Circle's version), demonstrating how abstract classes combine guaranteed shared behavior with mandatory subclass-specific customization.
Common Mistakes
- Attempting to Instantiate an Abstract Class or Interface Directly: Writing 'Shape myShape = new Shape("Red");' where Shape is declared 'abstract' (or attempting 'new Playable();' for an interface) results in a compile-time error: 'Shape is abstract; cannot be instantiated'. Abstract classes and interfaces can only be used as a TYPE for a reference variable, with the actual object being an instance of some concrete subclass or implementing class.
- Forgetting to Implement All Abstract Methods in a Concrete Subclass: If a non-abstract (concrete) class extends an abstract class or implements an interface but fails to provide an implementation for even one of the required abstract methods, the code fails to compile with an error like 'Circle is not abstract and does not override abstract method calculateArea() in Shape'. Every abstract method must be implemented by the first concrete (non-abstract) class in the inheritance chain.
- Confusing 'default' Interface Methods with Regular Class Inheritance: Beginners sometimes assume 'default' methods in an interface work exactly like inherited concrete methods from an abstract class in every way, but a key difference is that if a class implements multiple interfaces that both define a 'default' method with the identical signature, the implementing class MUST explicitly override that method itself to resolve the conflict, or it will fail to compile with a 'inherits unrelated defaults' error — unlike single-inheritance-based abstract classes, where no such conflict can arise.
- Adding Instance Fields to a Traditional Interface Expecting Object-Specific State: Any field declared inside an interface is implicitly 'public static final' (a constant), regardless of whether these modifiers are explicitly written. Beginners sometimes mistakenly expect to declare a regular, mutable instance field inside an interface to hold object-specific state, not realizing it's actually a shared constant, identical across every single implementing class, and cannot be reassigned by any implementing object.
Best Practices
- Use Interfaces to Define Contracts Across Unrelated Classes: Choose an interface when you need to define a common set of behaviors that potentially very different, unrelated classes must all support (like 'Comparable' or 'Playable'), especially when a class might need to fulfill multiple such behavioral contracts simultaneously by implementing several interfaces.
- Use Abstract Classes When Sharing Common State and Partial Implementation: Choose an abstract class when a group of closely related subclasses share significant common fields, constructors, or partially-complete method implementations, and genuinely fit an 'is-a' hierarchical relationship, allowing the shared logic to be written exactly once in the abstract superclass.
- Prefer Programming Against Interface Types for Flexibility: Declare reference variables and method parameters using the interface type (e.g., 'List<String> items' instead of 'ArrayList<String> items') wherever practical, allowing the underlying concrete implementation to be swapped later with minimal changes required elsewhere in the codebase.
- Keep Interfaces Focused (Interface Segregation Principle): Avoid designing large, bloated interfaces with many unrelated methods that force implementing classes to provide meaningless or empty implementations for methods they don't actually need. Instead, split large interfaces into several smaller, more focused ones, allowing classes to implement only the specific contracts genuinely relevant to them.
Interview Questions
What are the key differences between an abstract class and an interface in Java?
An abstract class can contain a mix of abstract methods, concrete (fully-implemented) methods, constructors, and both static and instance fields with any access modifier, but a class can only extend ONE abstract class due to Java's single-inheritance rule for classes. An interface, traditionally, could only contain abstract method signatures (implicitly public and abstract) and constant fields (implicitly public, static, final), though since Java 8 it can also include 'default' and 'static' methods with actual implementations; crucially, a class can implement MULTIPLE interfaces simultaneously. Use an abstract class when subclasses share substantial common state/implementation in a genuine 'is-a' hierarchy; use an interface to define a behavioral contract that potentially unrelated classes need to fulfill, especially when multiple such contracts might need to be satisfied by a single class.
What happens if a class implements two interfaces that both define a default method with the exact same signature?
This creates what's sometimes called the 'diamond problem' for default methods. Java does not automatically pick one interface's default method over the other, since doing so implicitly could introduce unpredictable, hard-to-trace behavior depending on interface declaration order. Instead, the implementing class is REQUIRED to explicitly override that specific method itself to resolve the ambiguity, or the code fails to compile with an error like 'class C inherits unrelated defaults for method() from types A and B'. Within its own override, the class can still selectively invoke one specific interface's default implementation using special syntax like 'InterfaceA.super.methodName();' if desired, rather than being forced to write entirely new logic from scratch.
Why can't an abstract class be instantiated directly, and how does an abstract method enforce a contract for its subclasses?
An abstract class cannot be instantiated directly because it represents an intentionally incomplete blueprint — it may contain abstract methods with no actual implementation at all, meaning calling such a method on a hypothetical direct instance would have genuinely undefined behavior with nothing to execute. Java's compiler prevents this ambiguity entirely by disallowing 'new' on any abstract class. An abstract method enforces a contract by requiring that the first CONCRETE (non-abstract) subclass in the inheritance chain must provide a complete, compilable implementation for every inherited abstract method; if even one abstract method remains unimplemented in a class that isn't itself declared abstract, the compiler raises an error, ensuring that by the time an actual object is created, every method it might be called upon has a genuine, executable implementation.
Practice Questions
Create an interface 'Drawable' with a method 'draw()', and implement it in two classes, 'Circle' and 'Square', each printing a different message. Demonstrate calling draw() on both through the Drawable interface type.
interface Drawable {
void draw();
}
class Circle implements Drawable {
@Override
public void draw() {
System.out.println("Drawing a circle");
}
}
class Square implements Drawable {
@Override
public void draw() {
System.out.println("Drawing a square");
}
}
public class DrawableDemo {
public static void main(String[] args) {
Drawable[] shapes = { new Circle(), new Square() };
for (Drawable shape : shapes) {
shape.draw();
}
}
}
// Output:
// Drawing a circle
// Drawing a square
What is wrong with the following code, and what compile-time error will occur?
abstract class Vehicle {
abstract void start();
}
class Car extends Vehicle {
// No implementation of start() provided
}
public class Test {
public static void main(String[] args) {
Car myCar = new Car();
}
}
The code fails to compile with an error similar to: 'Car is not abstract and does not override abstract method start() in Vehicle'. Since 'Car' extends the abstract 'Vehicle' class but does not itself provide an implementation for the inherited abstract method 'start()', and 'Car' is not itself declared as 'abstract', the compiler requires every concrete (non-abstract) class to fully implement all abstract methods it inherits. The fix is either to provide a concrete implementation of 'start()' inside 'Car' (e.g., 'void start() { System.out.println("Car starting"); }'), or to explicitly declare 'Car' itself as 'abstract class Car extends Vehicle' if it's intended to remain incomplete and be further subclassed later.
Create an interface 'Discountable' with a default method 'applyDiscount()' that prints a generic message, and a class 'PremiumProduct' that implements this interface without overriding the default method. Call it from main.
interface Discountable {
default void applyDiscount() {
System.out.println("Applying standard 10% discount");
}
}
class PremiumProduct implements Discountable {
// No override - uses the interface's default implementation
}
public class DefaultMethodDemo {
public static void main(String[] args) {
PremiumProduct product = new PremiumProduct();
product.applyDiscount();
}
}
// Output:
// Applying standard 10% discount
// Since PremiumProduct does not override applyDiscount(), it automatically uses the interface's own default implementation, demonstrating how default methods (introduced in Java 8) allow interfaces to provide ready-to-use behavior without forcing every implementing class to write its own version.
Summary
Interfaces and abstract classes are Java's two primary tools for achieving abstraction, allowing code to depend on high-level contracts rather than specific concrete implementations. Abstract classes suit closely related subclasses sharing common state and partial implementation within a single-inheritance hierarchy, while interfaces define behavioral contracts implementable across multiple, potentially unrelated classes, enhanced since Java 8 with default and static methods. Understanding when to choose each, along with rules around mandatory abstract method implementation and resolving conflicting default methods, is essential for designing flexible, extensible, real-world Java systems.
Was This Chapter Helpful?