Abstract Classes and Interfaces

The Purpose of Abstract Classes

An abstract class serves as a partial template for a family of related objects, allowing you to define a base state and shared functionality while forcing subclasses to implement specific, domain-dependent logic. By using the 'abstract' keyword, you inform the compiler that the class is incomplete and cannot be instantiated directly, effectively preventing misuse. The underlying reason for this design is to establish a 'is-a' relationship where subclasses inherit both characteristics and behavior from a common ancestor. When you have code that is identical across multiple subclasses, placing it in the base abstract class adheres to the DRY principle, reducing redundancy and ensuring consistent maintenance. If you later decide to modify a shared method, the change propagates automatically to every subclass, ensuring architectural integrity across your domain model without requiring modifications in numerous places throughout your codebase.

abstract class Document {
    protected String title; // Shared state for all documents

    public Document(String title) { this.title = title; }

    // Shared implementation
    public void printMetadata() { System.out.println("Doc: " + title); }

    // Force subclass implementation for specific logic
    public abstract void process();
}

class PdfDocument extends Document {
    public PdfDocument(String title) { super(title); }
    public void process() { System.out.println("Processing PDF"); }
}

Understanding Interfaces as Contracts

While abstract classes represent a hierarchy of related objects, interfaces define a behavioral contract that any class can adopt, regardless of its place in the class hierarchy. An interface is a pure abstraction that lists method signatures without providing their implementation details, essentially saying, 'Any object that implements this interface promises to provide these specific functions.' This is powerful because it decouples the object's identity from its capabilities. When you depend on an interface rather than a concrete class, your code becomes modular and highly testable; you can swap the implementation of a dependency at runtime without breaking the client that relies on it. Interfaces represent a 'can-do' relationship. This design allows for horizontal extensibility, where you can add new features or behaviors to existing classes simply by implementing a new interface, even if those classes reside deep within a completely different part of your application infrastructure.

interface Searchable {
    // Implicitly public and abstract
    boolean matches(String query);
}

class User implements Searchable {
    private String name;
    public User(String name) { this.name = name; }

    public boolean matches(String query) {
        return name.contains(query);
    }
}

Default Methods in Interfaces

Before modern Java versions, interfaces were strictly limited to method signatures, which created maintenance bottlenecks when an interface needed to be updated. If you added a method to an interface, every single implementation class broke immediately, requiring a manual update. Default methods solved this by allowing interfaces to provide a 'default' implementation for methods, which implementation classes can choose to override or use as-is. This feature effectively bridges the gap between interfaces and abstract classes. It allows you to evolve interfaces by adding new functionality without breaking existing classes that implement them. The reason this works without violating the single-inheritance rule for classes is that interfaces remain distinct from the state-heavy nature of inheritance. Default methods provide backward compatibility while keeping the contract focused on behavioral capability, ensuring that APIs can grow alongside application requirements without forcing unnecessary code refactoring across large, distributed project structures.

interface DataProcessor {
    void execute();

    // Default method provided for convenience
    default void logCompletion() {
        System.out.println("Process finished successfully.");
    }
}

class DataLogger implements DataProcessor {
    public void execute() { System.out.println("Executing logic"); }
    // No need to implement logCompletion()
}

Choosing Between Abstraction Types

Deciding whether to use an abstract class or an interface requires analyzing your domain. Choose an abstract class when you need to maintain state (fields) or when you need to provide access modifiers like 'protected' to restrict access to helper methods within a hierarchy. Abstract classes are superior for objects that share a deep, fundamental relationship where code reuse of internal state is paramount. Conversely, choose an interface when you want to define a cross-cutting concern that does not imply a shared parent, or when you need to support multiple inheritance of types, which Java allows for interfaces but not for classes. If you find yourself in a situation where classes are unrelated but must act in a uniform way when passed to a specific method, the interface is the correct choice. Interfaces promote a more flexible architecture by focusing on interaction protocols instead of shared biological lineage or internal structural organization.

// Abstract class for shared state
abstract class BaseWidget { protected int id; }

// Interface for shared behavior
interface Clickable { void onClick(); }

class Button extends BaseWidget implements Clickable {
    public void onClick() { System.out.println("Button " + id + " clicked"); }
}

Polymorphism and Loose Coupling

The true strength of abstract classes and interfaces lies in their ability to facilitate polymorphism, allowing a program to treat different objects as the same type based on their shared abstraction. When you declare a reference as an interface type, you are hiding the concrete implementation from the consumer. This technique, often called 'programming to an interface,' enables you to swap implementations easily, such as replacing a real database connector with a mock version during unit testing. Because the client code only knows about the methods defined in the interface or abstract base class, it remains completely agnostic about the internal mechanics of the object it uses. This reduces the surface area for bugs, as changing the underlying implementation logic of a concrete class does not ripple through your application, provided the method signature and the defined contract remain consistent for all callers within the system.

import java.util.ArrayList;
import java.util.List;

public class Engine {
    // Polymorphic collection relying on the interface
    public void processAll(List<Searchable> items) {
        for (Searchable item : items) {
            item.matches("test");
        }
    }
}

Interview questions

All java interview questions →

Check yourself

Take the full java quiz →