Abstraction is the principle of hiding complexity and exposing only what is necessary. You interact with a car through a steering wheel, pedals, and a gear lever — the engine internals, fuel injection timing, and combustion mechanics are hidden. The interface is simple; the implementation is complex. That is abstraction.

In Java, abstraction is achieved through two mechanisms: abstract classes and interfaces. Both define what an object can do without specifying how it does it. The caller writes code against the contract — the what — and each implementation class provides the how. The caller never needs to change when the how changes.

What Is Abstraction in Java?

Abstraction is the OOP principle of exposing only essential behaviour while hiding implementation details. It separates the definition of operations from their execution.

A class that declares a method without providing its body is abstract. It tells every subclass: "You must implement this." The abstract class defines the contract; concrete subclasses fulfil it. Callers that work with the abstract type automatically get the correct behaviour regardless of which concrete type they receive.

Java provides two mechanisms for abstraction:

Mechanism	Keyword	Can Have Concrete Methods	Can Have State (Fields)	Multiple Inheritance
Abstract class	`abstract class`	Yes	Yes	No — single extends
Interface	`interface`	Yes (default methods)	No (only constants)	Yes — multiple implements

Why Abstraction Matters

Without abstraction, every caller must know the concrete type it is dealing with and must change whenever that type changes. With abstraction, callers depend on a stable contract — the interface — and the implementation can evolve freely behind it.

The practical outcomes:

›Replaceability — swap RazorpayGateway for PayUGateway without touching the payment service
›Testability — inject a mock implementation during tests without modifying the system under test
›Extensibility — add new notification channels without changing the notification dispatcher
›Reduced coupling — the caller depends on the contract, not the implementation class name

Abstract Classes

An abstract class is a class declared with the abstract keyword. It cannot be instantiated directly — you cannot write new AbstractClass(). It may contain:

›Abstract methods — declared without a body; subclasses must implement them
›Concrete methods — fully implemented; subclasses inherit and may override them
›Fields — instance variables, static fields, constants
›Constructors — called by subclass constructors through super()

Java

// File: ReportGenerator.java

public abstract class ReportGenerator {

    private final String reportTitle;
    private final String generatedBy;

    public ReportGenerator(String reportTitle, String generatedBy) {
        this.reportTitle = reportTitle;
        this.generatedBy = generatedBy;
    }

    public String getReportTitle() { return reportTitle; }
    public String getGeneratedBy() { return generatedBy; }

    // Abstract — each subclass fetches data differently
    protected abstract String fetchData();

    // Abstract — each subclass formats output differently
    protected abstract String formatReport(String data);

    // Concrete — the generation flow is fixed for all subclasses
    public final String generate() {
        String header = "=== " + reportTitle + " ==="
                + "\nGenerated by: " + generatedBy + "\n";
        String data   = fetchData();           // subclass provides data
        String body   = formatReport(data);    // subclass formats it
        return header + body;
    }
}

Java

// File: SalesReport.java

public class SalesReport extends ReportGenerator {

    private final double totalSales;
    private final int    totalOrders;
    private final String region;

    public SalesReport(String generatedBy, double totalSales,
                       int totalOrders, String region) {
        super("Sales Report", generatedBy);
        this.totalSales  = totalSales;
        this.totalOrders = totalOrders;
        this.region      = region;
    }

    @Override
    protected String fetchData() {
        // Simulates fetching from a database or analytics service
        return "Region: " + region
                + " | Orders: " + totalOrders
                + " | Total Sales: Rs." + totalSales;
    }

    @Override
    protected String formatReport(String data) {
        double avgOrderValue = totalOrders > 0 ? totalSales / totalOrders : 0;
        return data + "\nAverage order value: Rs."
                + String.format("%.2f", avgOrderValue);
    }
}

Java

// File: InventoryReport.java

public class InventoryReport extends ReportGenerator {

    private final int    totalSkus;
    private final int    outOfStockSkus;
    private final String warehouseId;

    public InventoryReport(String generatedBy, int totalSkus,
                            int outOfStockSkus, String warehouseId) {
        super("Inventory Report", generatedBy);
        this.totalSkus      = totalSkus;
        this.outOfStockSkus = outOfStockSkus;
        this.warehouseId    = warehouseId;
    }

    @Override
    protected String fetchData() {
        return "Warehouse: " + warehouseId
                + " | Total SKUs: " + totalSkus
                + " | Out of stock: " + outOfStockSkus;
    }

    @Override
    protected String formatReport(String data) {
        double stockHealthPercent = totalSkus > 0
                ? ((double)(totalSkus - outOfStockSkus) / totalSkus) * 100 : 0;
        return data + "\nStock health: "
                + String.format("%.1f", stockHealthPercent) + "%";
    }
}

Java

// File: AbstractClassDemo.java

public class AbstractClassDemo {

    public static void main(String[] args) {

        ReportGenerator salesReport = new SalesReport(
                "Priya Mehta", 485000.0, 320, "South India"
        );

        ReportGenerator inventoryReport = new InventoryReport(
                "Rahul Desai", 2450, 187, "WH-PUNE-01"
        );

        System.out.println(salesReport.generate());
        System.out.println();
        System.out.println(inventoryReport.generate());
    }
}

Output:
=== Sales Report ===
Generated by: Priya Mehta
Region: South India | Orders: 320 | Total Sales: Rs.485000.0
Average order value: Rs.1515.63

=== Inventory Report ===
Generated by: Rahul Desai
Warehouse: WH-PUNE-01 | Total SKUs: 2450 | Out of stock: 187
Stock health: 92.4%

generate() is final and concrete — it defines the algorithm structure. fetchData() and formatReport() are abstract — each subclass fills in the missing pieces. This is the Template Method Pattern: the parent controls the flow; the children provide the content. Abstraction is what makes this work — the generate() method does not know or care whether it is generating a sales report or inventory report.

Interfaces

An interface is a fully abstract type that defines a contract — a set of method signatures that implementing classes must provide. Since Java 8, interfaces can also contain default and static methods with implementations.

Java

// File: PaymentGateway.java

public interface PaymentGateway {

    // Abstract methods — every implementor must provide these
    boolean initiatePayment(String orderId, double amount, String currency);
    boolean verifyPayment(String transactionId);
    boolean refundPayment(String transactionId, double amount);

    // Default method — shared logic available to all implementations
    default String buildPaymentRef(String orderId) {
        return "PAY-" + orderId + "-" + System.currentTimeMillis();
    }

    // Static method — utility on the interface itself
    static boolean isValidAmount(double amount) {
        return amount > 0 && amount <= 1000000.0;
    }
}

Java

// File: RazorpayGateway.java

public class RazorpayGateway implements PaymentGateway {

    private final String apiKey;

    public RazorpayGateway(String apiKey) {
        this.apiKey = apiKey;
    }

    @Override
    public boolean initiatePayment(String orderId, double amount, String currency) {
        String ref = buildPaymentRef(orderId); // inherited default method
        System.out.println("Razorpay: initiating " + ref
                + " | Rs." + amount + " " + currency
                + " [key: " + apiKey.substring(0, 8) + "...]");
        return true;
    }

    @Override
    public boolean verifyPayment(String transactionId) {
        System.out.println("Razorpay: verifying " + transactionId);
        return true;
    }

    @Override
    public boolean refundPayment(String transactionId, double amount) {
        System.out.println("Razorpay: refunding Rs." + amount
                + " for " + transactionId);
        return true;
    }
}

Java

// File: PayUGateway.java

public class PayUGateway implements PaymentGateway {

    private final String merchantId;

    public PayUGateway(String merchantId) {
        this.merchantId = merchantId;
    }

    @Override
    public boolean initiatePayment(String orderId, double amount, String currency) {
        String ref = buildPaymentRef(orderId); // inherited default method
        System.out.println("PayU: initiating " + ref
                + " | Rs." + amount + " " + currency
                + " [merchant: " + merchantId + "]");
        return true;
    }

    @Override
    public boolean verifyPayment(String transactionId) {
        System.out.println("PayU: verifying " + transactionId);
        return true;
    }

    @Override
    public boolean refundPayment(String transactionId, double amount) {
        System.out.println("PayU: refunding Rs." + amount
                + " for " + transactionId);
        return true;
    }
}

Java

// File: InterfaceDemo.java

public class InterfaceDemo {

    // Works with any PaymentGateway — abstraction in action
    public static void processOrder(String orderId, double amount,
                                     PaymentGateway gateway) {
        if (!PaymentGateway.isValidAmount(amount)) {
            System.out.println("Invalid amount: Rs." + amount);
            return;
        }
        boolean initiated = gateway.initiatePayment(orderId, amount, "INR");
        if (initiated) {
            System.out.println("  Payment initiated for " + orderId);
        }
    }

    public static void main(String[] args) {

        PaymentGateway razorpay = new RazorpayGateway("rzp_live_abc12345xyz");
        PaymentGateway payU     = new PayUGateway("PAYU_MERCHANT_007");

        processOrder("ORD-1001", 1499.0, razorpay);
        System.out.println();
        processOrder("ORD-1002", 3999.0, payU);
        System.out.println();
        processOrder("ORD-1003", -500.0, razorpay); // invalid amount
    }
}

Output:
Razorpay: initiating PAY-ORD-1001-1704067200000 | Rs.1499.0 INR [key: rzp_live...]
  Payment initiated for ORD-1001

PayU: initiating PAY-ORD-1002-1704067200001 | Rs.3999.0 INR [merchant: PAYU_MERCHANT_007]
  Payment initiated for ORD-1002

Invalid amount: Rs.-500.0

processOrder() accepts a PaymentGateway reference — it does not know whether it is dealing with Razorpay or PayU. Switching the entire payment provider for any order requires changing one line at the call site — the object creation. The processing logic never changes. This is abstraction's core promise: the caller is immune to implementation changes.

Abstraction vs Encapsulation

These two pillars are the most consistently confused pair in Java OOP interviews. Understanding their precise distinction matters.

Aspect	Abstraction	Encapsulation
Core idea	Hide complexity — show only what the object does	Hide data — protect internal state from direct access
Focus	The interface or contract exposed to the world	The data and how it is protected within a class
Answers the question	"What can this object do?"	"How is the data protected inside this object?"
Implemented using	Abstract classes, interfaces	`private` fields, getters, setters
Level	System-level — design principle across classes	Class-level — within a single class
Goal	Reduce complexity for the caller	Protect data integrity and control modification
Example	`PaymentGateway` interface hides Razorpay vs PayU	`private double balance` with `deposit()` and `withdraw()`
Runtime behaviour	Enforced through polymorphism at runtime	Enforced by access modifiers at compile time
Change impact	New implementation — no caller change needed	Internal storage change — no caller change needed

The clearest way to remember it: Encapsulation hides the contents of a class (its data). Abstraction hides the existence of implementation details (the how behind a contract). Both hide things — different things, at different levels.

Abstract Class vs Interface

Aspect	Abstract Class	Interface
Keyword	`abstract class`	`interface`
Instantiation	Cannot be instantiated	Cannot be instantiated
Methods	Abstract and concrete	Abstract, default (Java 8+), static (Java 8+)
Fields	Instance fields, static fields, constants	Only `public static final` constants
Constructors	Yes — called via `super()` in subclasses	No
Access modifiers on methods	Any	`public` by default (abstract methods)
Multiple inheritance	No — `extends` one class only	Yes — `implements` multiple interfaces
`extends` / `implements`	Child uses `extends`	Class uses `implements`
IS-A relationship	Yes — concrete subtype	Yes — capability contract
When to use	Shared code + partial implementation	Pure contract, multiple inheritance of type

Levels of Abstraction in Java

Abstraction exists on a spectrum — from fully concrete (no abstraction) to fully abstract (pure contract).

Fully Concrete Class
(all methods implemented, can be instantiated)
         |
         |   ← add abstract methods
         ↓
Abstract Class
(mix of abstract + concrete methods, cannot be instantiated)
         |
         |   ← remove all concrete methods and fields
         ↓
Interface (pre-Java 8)
(only abstract method signatures, no implementation)
         |
         |   ← add default/static methods
         ↓
Interface (Java 8+)
(abstract + default + static methods, still no state)

The right level of abstraction depends on what callers need to know and what implementations need to share. If different implementations share some common logic, an abstract class with concrete methods is appropriate. If the only need is a contract with no shared implementation, an interface is cleaner.

Real-World Example — Delivery Notification System

The Business Problem

You are building the delivery notification system for a quick-commerce platform — similar to what Zepto or Swiggy Instamart runs for its real-time order updates. The system must send notifications through multiple channels — SMS, email, and in-app push. Each channel has different sending logic. The notification dispatcher must send through all configured channels without knowing which specific implementations it is dealing with.

Implementation

Java

// File: NotificationChannel.java

public interface NotificationChannel {

    // Every channel must implement these
    boolean send(String recipientId, String message);
    String  getChannelName();

    // Default — shared validation logic available to all channels
    default boolean isValidMessage(String message) {
        return message != null && !message.isBlank() && message.length() <= 500;
    }
}

Java

// File: BaseNotificationChannel.java

public abstract class BaseNotificationChannel implements NotificationChannel {

    private final String channelName;
    private       int    messagesSentToday;

    protected BaseNotificationChannel(String channelName) {
        this.channelName        = channelName;
        this.messagesSentToday  = 0;
    }

    @Override
    public String getChannelName() { return channelName; }

    public int getMessagesSentToday() { return messagesSentToday; }

    // Template method — enforces validation before sending
    @Override
    public final boolean send(String recipientId, String message) {
        if (!isValidMessage(message)) {
            System.out.println("[" + channelName + "] Invalid message — skipping.");
            return false;
        }
        boolean result = doSend(recipientId, message); // subclass provides the actual send
        if (result) messagesSentToday++;
        return result;
    }

    // Abstract — each channel provides its own sending implementation
    protected abstract boolean doSend(String recipientId, String message);
}

Java

// File: SmsChannel.java

public class SmsChannel extends BaseNotificationChannel {

    private final String smsApiEndpoint;

    public SmsChannel(String smsApiEndpoint) {
        super("SMS");
        this.smsApiEndpoint = smsApiEndpoint;
    }

    @Override
    protected boolean doSend(String recipientId, String message) {
        System.out.println("  [SMS] Sending to " + recipientId
                + " via " + smsApiEndpoint + ": " + message);
        return true;
    }
}

Java

// File: EmailChannel.java

public class EmailChannel extends BaseNotificationChannel {

    private final String smtpServer;
    private final String senderEmail;

    public EmailChannel(String smtpServer, String senderEmail) {
        super("Email");
        this.smtpServer  = smtpServer;
        this.senderEmail = senderEmail;
    }

    @Override
    protected boolean doSend(String recipientId, String message) {
        System.out.println("  [Email] From: " + senderEmail
                + " via " + smtpServer
                + " | To: " + recipientId + " | " + message);
        return true;
    }
}

Java

// File: PushChannel.java

public class PushChannel extends BaseNotificationChannel {

    private final String fcmApiKey;

    public PushChannel(String fcmApiKey) {
        super("Push");
        this.fcmApiKey = fcmApiKey;
    }

    @Override
    protected boolean doSend(String recipientId, String message) {
        System.out.println("  [Push] Sending to device: " + recipientId
                + " [FCM key: " + fcmApiKey.substring(0, 6) + "...] | " + message);
        return true;
    }
}

Java

// File: NotificationDispatcher.java

import java.util.List;

public class NotificationDispatcher {

    private final List<NotificationChannel> channels;

    public NotificationDispatcher(List<NotificationChannel> channels) {
        this.channels = channels;
    }

    // Works with any NotificationChannel — abstraction decouples dispatcher from implementations
    public void dispatch(String recipientId, String message) {
        System.out.println("Dispatching to " + channels.size() + " channel(s):");
        int successCount = 0;
        for (NotificationChannel channel : channels) {
            boolean sent = channel.send(recipientId, message);
            if (sent) successCount++;
        }
        System.out.println("Sent via " + successCount + "/" + channels.size() + " channels.\n");
    }
}

Java

// File: NotificationDemo.java

import java.util.List;

public class NotificationDemo {

    public static void main(String[] args) {

        List<NotificationChannel> channels = List.of(
                new SmsChannel("https://sms.twilio.com/api"),
                new EmailChannel("smtp.sendgrid.net", "noreply@zepto.co"),
                new PushChannel("AAAA_FCM_API_KEY_xyz")
        );

        NotificationDispatcher dispatcher = new NotificationDispatcher(channels);

        System.out.println("=== Order Shipped Notification ===");
        dispatcher.dispatch("USER-9876",
                "Your order ORD-4521 has been shipped. Expected delivery: 2 hours.");

        System.out.println("=== OTP Notification ===");
        dispatcher.dispatch("USER-1234", "Your OTP is 847291. Valid for 5 minutes.");

        // Invalid message — too long or blank
        System.out.println("=== Invalid Message Test ===");
        dispatcher.dispatch("USER-5555", "");
    }
}

Output:
=== Order Shipped Notification ===
Dispatching to 3 channel(s):
  [SMS] Sending to USER-9876 via https://sms.twilio.com/api: Your order ORD-4521 has been shipped. Expected delivery: 2 hours.
  [Email] From: noreply@zepto.co via smtp.sendgrid.net | To: USER-9876 | Your order ORD-4521 has been shipped. Expected delivery: 2 hours.
  [Push] Sending to device: USER-9876 [FCM key: AAAA_F...] | Your order ORD-4521 has been shipped. Expected delivery: 2 hours.
Sent via 3/3 channels.

=== OTP Notification ===
Dispatching to 3 channel(s):
  [SMS] Sending to USER-1234 via https://sms.twilio.com/api: Your OTP is 847291. Valid for 5 minutes.
  [Email] From: noreply@zepto.co via smtp.sendgrid.net | To: USER-1234 | Your OTP is 847291. Valid for 5 minutes.
  [Push] Sending to device: USER-1234 [FCM key: AAAA_F...] | Your OTP is 847291. Valid for 5 minutes.
Sent via 3/3 channels.

=== Invalid Message Test ===
Dispatching to 3 channel(s):
[SMS] Invalid message — skipping.
[Email] Invalid message — skipping.
[Push] Invalid message — skipping.
Sent via 0/3 channels.

The NotificationDispatcher depends only on NotificationChannel — an interface. Adding a WhatsAppChannel requires creating one new class that implements NotificationChannel. The dispatcher, all existing channels, and every test remain unchanged. The abstraction layer absorbed the extension completely.

BaseNotificationChannel provides shared concrete behaviour — the validation-before-send template and the message counter — while keeping doSend() abstract. This is the layered abstraction pattern: interface defines the contract, abstract class provides partial implementation, concrete classes complete it.

Best Practices

Depend on abstractions — never on concrete implementations

The Dependency Inversion Principle states that high-level modules should depend on abstractions, not on concrete classes. A CheckoutService that declares PaymentGateway gateway as a field can work with any gateway. A CheckoutService that declares RazorpayGateway gateway is tightly coupled to one provider. Every time you write a type name in a parameter or field, ask: can I make this an interface or abstract class?

Use interfaces for pure contracts, abstract classes for shared implementation

If different implementations have nothing in common except the method signatures they must provide, use an interface. If they share some implementation — a validation step, a logging call, a counter — use an abstract class that provides the shared concrete methods and declares the variable parts as abstract. Both mechanisms serve abstraction; the right choice depends on what implementations share.

Keep abstract method count low — each one is a burden on every implementor

Every abstract method in an abstract class or interface is something every concrete subclass must implement. An interface with twelve abstract methods forces every implementor to write twelve methods — including mock implementations in tests. Keep the contract focused. If an interface has grown large, consider splitting it into smaller role-specific interfaces. This is the Interface Segregation Principle.

Name abstractions after what they do, not what they are

PaymentGateway names a capability — what objects of this type can do. AbstractPayment names a structural classification — what the type is in the hierarchy. The first is a better abstraction name because it focuses on behaviour. Interfaces especially should be named as capabilities or roles: Printable, Comparable, NotificationChannel, DataFetcher.

Common Mistakes

Mistake 1 — Instantiating an Abstract Class

Java

public abstract class Shape {
    public abstract double area();
}

public class Main {
    public static void main(String[] args) {
        Shape shape = new Shape(); // compile error — Shape is abstract
        // Cannot instantiate abstract class
    }
}

Compile error: Shape is abstract; cannot be instantiated

Abstract classes exist to be extended — they cannot be instantiated directly. To get an object, create a concrete subclass. To declare a variable, use the abstract type — Shape shape = new Circle(5.0) is valid because Circle is concrete.

Mistake 2 — Providing Implementation in Every Abstract Class Method

Java

// Wrong — if all methods are concrete, why is the class abstract?
public abstract class DataExporter {
    public void export(String data) {
        System.out.println("Exporting: " + data); // fully concrete
    }
    public void validate(String data) {
        System.out.println("Validating: " + data); // fully concrete
    }
    // No abstract methods — this should just be a regular class
}

An abstract class with no abstract methods can be declared as abstract to prevent instantiation, but this is rare. If there are no abstract methods, a regular class with a protected constructor usually serves better. The defining purpose of an abstract class is that it has at least one method that subclasses must implement.

Mistake 3 — Using Abstract Class When an Interface Is Sufficient

Java

// Wrong — no shared state, no shared implementation needed
// This should be an interface
public abstract class Printable {
    public abstract void print();
    public abstract String getContent();
    // No fields, no concrete methods — interface is cleaner
}

// Correct
public interface Printable {
    void print();
    String getContent();
}

When an abstract class has only abstract methods and no fields or concrete methods, it is functionally identical to an interface — but more restrictive, because a class can only extend one abstract class. Prefer interfaces for pure contracts; they allow implementing classes more flexibility.

Mistake 4 — Exposing Implementation Details Through the Abstract Interface

Java

// Wrong — getInternalDbConnection() leaks implementation detail
public interface ReportService {
    List<Report> getReports();
    void generateReport(String type);
    Connection getInternalDbConnection(); // leaks that this uses JDBC internally
}

// Correct — only expose what callers need
public interface ReportService {
    List<Report> getReports();
    void generateReport(String type);
}

An abstract interface that exposes implementation-specific methods — internal connections, file handles, adapter instances — defeats the purpose of abstraction. Callers should see only the operations they need. Anything implementation-specific belongs in the concrete class, not in the interface.

Interview Questions

Q1. What is abstraction in Java and how is it achieved?

Abstraction is the OOP principle of hiding implementation complexity and exposing only essential behaviour through a clean interface. In Java, it is achieved through two mechanisms: abstract classes — which can have both abstract (bodyless) and concrete methods, can hold fields, and are extended using extends — and interfaces — which define a pure contract of method signatures that implementing classes must provide, using implements. Both allow callers to write code against the type definition rather than the specific implementation.

Q2. What is the difference between abstraction and encapsulation?

Abstraction hides complexity at the system level — it shows what an object does through an interface without revealing how it does it. Encapsulation hides data at the class level — it protects internal fields from direct external access using private modifiers and controlled methods. Abstraction is about the contract presented to callers across class boundaries. Encapsulation is about protecting state within a single class. Both hide things — abstraction hides the implementation; encapsulation hides the data.

Q3. What is the difference between an abstract class and an interface in Java?

An abstract class can have concrete and abstract methods, can hold instance fields, has constructors, and is extended with extends — a class can extend only one. An interface defines abstract method signatures, can have default and static methods since Java 8, can only hold constants (public static final), has no constructors, and is implemented with implements — a class can implement multiple interfaces. Use an abstract class when implementations share concrete behaviour or state. Use an interface for a pure contract or when multiple inheritance of type is needed.

Q4. Can you instantiate an abstract class in Java?

No. An abstract class cannot be instantiated with new. It exists to be extended by concrete subclasses. However, you can declare a variable of the abstract class type and assign a concrete subclass object to it — this is upcasting, which enables runtime polymorphism. An abstract class with no abstract methods can technically exist, and is used to prevent direct instantiation while still providing shared implementation.

Q5. What is the Template Method Pattern and how does it use abstraction?

The Template Method Pattern defines the skeleton of an algorithm in an abstract class — using a concrete method that calls abstract methods in a fixed sequence. The abstract class controls the flow; the subclasses provide the variable pieces. generate() in ReportGenerator calls fetchData() and formatReport() — both abstract — in a fixed order. Each subclass implements these steps differently without altering the overall flow. This is abstraction enabling the Open-Closed Principle: the algorithm is closed for modification but open for extension through new subclasses.

Q6. What is the Dependency Inversion Principle and how does abstraction support it?

The Dependency Inversion Principle states that high-level modules should not depend on low-level modules — both should depend on abstractions. A CheckoutService that depends on PaymentGateway (an interface) rather than RazorpayGateway (a concrete class) can work with any gateway implementation — present or future — without modification. Abstraction is the mechanism that makes this possible: the interface defines the contract both the high-level service and low-level implementation depend on. This is why every major Java framework — Spring, Jakarta EE — uses interface-based injection rather than concrete class injection.

FAQs

What is abstraction in Java in simple terms?

Abstraction means hiding the complex inner workings and showing only what is needed. When you call gateway.initiatePayment(), you do not need to know whether it is sending an HTTP request to Razorpay or PayU. You know what the method does — you do not know how. That separation of what from how is abstraction.

What is an abstract class in Java?

An abstract class is a class declared with the abstract keyword that cannot be instantiated directly. It can contain abstract methods — which subclasses must implement — and concrete methods with full implementations that subclasses inherit. It is used when multiple classes share some common behaviour but each also has a unique implementation of certain operations.

What is the difference between abstract class and interface in Java?

An abstract class can have fields, constructors, and both concrete and abstract methods — a class extends only one. An interface has only abstract methods, default methods (Java 8+), and constants — a class can implement many. Use an abstract class when implementations share state or concrete behaviour. Use an interface for a pure contract or when you need multiple type inheritance.

Can an abstract class have a constructor in Java?

Yes. An abstract class can have constructors. They are not called directly — since you cannot instantiate the abstract class — but they are called through super() in the child constructor. This is how the abstract class initialises its own fields before the child sets up its own.

Can an interface have a constructor in Java?

No. Interfaces cannot have constructors because they cannot be instantiated. Since Java 8, they can have default and static method implementations, but all state initialisation must happen in the implementing class.

What is the difference between interface and abstract class for testability?

Both improve testability by allowing mock implementations to be injected. Interfaces are typically preferred for testability because creating a mock interface requires less code — just implement the method signatures. Mocking abstract classes requires subclassing and potentially setting up inherited concrete state. Most mocking frameworks (Mockito) work equally well with both, but interfaces produce cleaner and more minimal test doubles.

Summary

Abstraction is the principle of hiding complexity and exposing only the contract. Java provides two mechanisms: abstract classes for partial abstraction — mixing concrete shared behaviour with abstract variable behaviour — and interfaces for pure abstraction — defining what must be done without any implementation. Both decouple callers from implementations, making systems extensible without modification.

The Template Method Pattern demonstrates abstract classes delivering abstraction: the flow is fixed, the steps are variable. The Dependency Inversion Principle demonstrates interfaces delivering abstraction: depend on the contract, not the class name. Both patterns appear in virtually every production Java codebase and every Java framework.

For interviews, be ready to explain the difference between abstraction and encapsulation precisely — they hide different things at different levels. Know the abstract class vs interface trade-off and when to use each. Demonstrate the Template Method Pattern and explain how it enables the open-closed principle. These points appear consistently in both service-based recall questions and product-based design discussions.

What to Read Next

Topic	Link
How interfaces define pure contracts and support multiple type inheritance	Interfaces →
How abstract classes provide partial implementation in inheritance hierarchies	Abstract Classes →
How encapsulation protects data while abstraction hides complexity	Encapsulation →
How polymorphism uses abstraction to enable runtime method dispatch	Polymorphism →
How inheritance provides the class hierarchy that abstraction is built on	Inheritance →

←

Previousinstanceof Operator

NextAbstract Classes

→