What is the difference between an interface and an abstract class?

Question

Accepted Answer

Both define abstract types that can't be instantiated directly and are meant to be implemented/extended — but they serve different design purposes. The key distinctions are **multiple inheritance**, **state**, and the relationship they model.

## Interface — a contract ("can-do" / capability)

```java
public interface Drawable {
    void draw();                          // abstract method (implicitly public abstract)

default void render() {                // default method — has a body (Java 8+)
        System.out.println("rendering");
    }
    int MAX = 100;                         // implicitly public static final (constant only)
}

class Circle implements Drawable {
    public void draw() { /* must implement */ }
}
```

An interface defines a **contract** of behavior. A class can implement **multiple** interfaces — this is how Java achieves a form of multiple inheritance. Interfaces (traditionally) have no instance state.

## Abstract class — a partial base ("is-a" with shared code)

```java
public abstract class Animal {
    protected String name;                 // ✅ can have instance FIELDS (state)

public Animal(String name) {           // ✅ can have a constructor
        this.name = name;
    }
    public abstract void makeSound();      // abstract — subclasses must implement
    public void sleep() {                   // ✅ concrete method with shared logic
        System.out.println(name + " sleeps");
    }
}

class Dog extends Animal {                 // can extend only ONE class
    public Dog(String n) { super(n); }
    public void makeSound() { System.out.println("Woof"); }
}
```

An abstract class can hold **state (fields)**, **constructors**, and concrete methods with shared implementation — but a class can extend only **one** abstract class (single inheritance).

## Key differences

```text
                    Interface              Abstract class
Multiple inheritance ✓ (implement many)    ✗ (extend only one)
Instance fields/state ✗ (constants only)   ✓ (fields)
Constructor           ✗                    ✓
Method bodies         default/static only  ✓ (concrete methods)
Models                capability ("can-do") "is-a" with shared base
```

## When to use which

```text
Interface → define a capability multiple unrelated classes can have
            (Comparable, Runnable, Serializable); when you need multiple inheritance
Abstract class → share common state + code among closely related subclasses
            (a base class with fields and partial implementation)
```

## Why it matters

Choosing between an interface and an abstract class is a fundamental Java design decision.

Interfaces define **contracts/capabilities** and enable a class to implement many of them (Java's answer to multiple inheritance) — ideal for cross-cutting abilities.

Abstract classes provide a **shared base with state and partial implementation** for closely-related subclasses, but limit you to single inheritance.

Understanding the trade-offs (multiple-implementation vs shared-state/constructors, capability vs is-a relationship) guides good API and class-hierarchy design.

With Java 8+ default methods blurring the line, knowing when each fits — and the core constraints (one abstract class but many interfaces, state only in abstract classes) — is essential for designing flexible, well-structured code.