Difference Between Abstract Class and Interface

"What is the difference between an abstract class and an interface?" may be the most asked Java interview question of all. Since Java 8 gave interfaces default methods, the two look more alike than they used to, so the answer has changed. The short version: an interface defines what a type can do and can be added to any class; an abstract class is a partly built class that shares state and code with a family of subclasses.

Side by Side

How to Choose

• Choose an interface when unrelated classes need the same ability, when a class may need several such abilities, or when you're defining a type others will implement.
• Choose an abstract class when closely related classes share fields, constructors or protected helper methods, or you want to lock steps with final template methods.
• When in doubt, start with an interface. A class can implement it without giving up its only extends.

Using Both: The Skeletal Implementation

Library designers often offer both: an interface as the public type, and an abstract class that implements it partly, so writing a new implementation is quick. The JDK does this with List and AbstractList, and Map and AbstractMap.

public class Skeleton {
    interface PaymentMethod {
        String pay(long amount);
        int count();
    }
 
    abstract static class BasePayment implements PaymentMethod {
        private final String label;
        private int count;
 
        BasePayment(String label) { this.label = label; }
 
        public final String pay(long amount) {
            count++;
            return label + " #" + count + ": " + process(amount);
        }
 
        public int count() { return count; }
 
        protected abstract String process(long amount);
    }
 
    static class Upi extends BasePayment {
        Upi() { super("UPI"); }
        protected String process(long amount) {
            return "Rs. " + amount + " sent";
        }
    }
 
    static class Card extends BasePayment {
        Card() { super("Card"); }
        protected String process(long amount) {
            return "Rs. " + (amount + amount * 2 / 100) + " charged";
        }
    }
 
    public static void main(String[] args) {
        PaymentMethod upi = new Upi();
        PaymentMethod card = new Card();
        System.out.println(upi.pay(500));
        System.out.println(upi.pay(120));
        System.out.println(card.pay(1000));
        System.out.println("UPI payments: " + upi.count());
    }
}

UPI #1: Rs. 500 sent
UPI #2: Rs. 120 sent
Card #1: Rs. 1020 charged
UPI payments: 2

How it works

1. PaymentMethod is the type everyone uses; main never mentions BasePayment.
2. BasePayment holds the state an interface can't: a label and a counter, set up by a constructor.
3. Its final pay method fixes the steps; subclasses only supply process, which is protected, another thing an interface can't offer.
4. A class that already extends something else could still implement PaymentMethod directly, without the skeleton.

Common Mistakes

Answering with the pre-Java 8 list. "Interfaces can't have method bodies" is no longer true; mention default, static and private methods.

Choosing an abstract class for an ability. abstract class Billable would stop a SchoolFee that already extends something else from being billable.

Putting state in an interface through constants. Interface fields are shared constants, not per-object data.

Interview Corner

Practice

1. Easy: For each, choose abstract class or interface and say why: Shape with a stored color; Printable; Vehicle with a registration number; Comparable.
2. Harder: Add a NetBanking class to Skeleton.java with a flat fee of Rs. 10, then add a Wallet class that implements PaymentMethod directly without BasePayment.

Key Takeaways