Java Abstract Classes: abstract Keyword Explained

What an Abstract Class Is

An interface declares behavior with no state. A regular class is fully implemented and can be instantiated. An abstract class sits between the two: it can carry fields, constructors, and finished methods like a normal class, but it can also leave some methods unimplemented and forbids being instantiated directly. You mark it with the abstract keyword.

The idea is to capture everything subclasses have in common in one place, while forcing each subclass to fill in the parts that genuinely differ.

abstract class Animal {
    private final String name;

    Animal(String name) { this.name = name; }   // shared constructor

    String getName() { return name; }            // shared, finished method

    abstract String sound();                     // no body - each subclass decides
}

class Dog extends Animal {
    Dog(String name) { super(name); }
    String sound() { return "Woof"; }
}

public class Main {
    public static void main(String[] args) {
        Animal a = new Dog("Rex");
        System.out.println(a.getName() + " says " + a.sound());
    }
}

Animal defines getName() once for every subclass and declares sound() as abstract - a method with a signature but no body that Dog must supply.

You Cannot Instantiate an Abstract Class

Because an abstract class may have unfinished methods, creating one directly would leave you with an incomplete object. The compiler rejects it:

Animal a = new Animal("???");   // error: Animal is abstract; cannot be instantiated

You always instantiate a concrete subclass - one that has implemented every abstract method. That subclass instance can then be held in a variable of the abstract type, which is exactly how you use the abstraction.

Abstract Methods Force Subclasses to Decide

An abstract method is a promise the subclass must keep. If a subclass forgets to implement one, the subclass itself becomes abstract and the compiler tells you so. This is the abstract class's main lever: it guarantees that certain behavior exists without dictating what it does.

abstract class Shape {
    abstract double area();                       // every shape must define this

    void describe() {                             // shared, written once
        System.out.printf("%s with area %.2f%n",
            getClass().getSimpleName(), area());
    }
}

class Circle extends Shape {
    private final double r;
    Circle(double r) { this.r = r; }
    double area() { return Math.PI * r * r; }
}

class Square extends Shape {
    private final double side;
    Square(double side) { this.side = side; }
    double area() { return side * side; }
}

public class Main {
    public static void main(String[] args) {
        Shape[] shapes = { new Circle(2), new Square(3) };
        for (Shape s : shapes) {
            s.describe();                         // calls the right area() automatically
        }
    }
}

describe() is written once in Shape yet calls each subclass's own area(). The abstract class supplies the common scaffolding; the subclasses supply the specifics.

Shared State and Constructors

Unlike a traditional interface, an abstract class can hold instance fields and define constructors. The constructor never makes an Animal or Shape by itself - it runs via super(...) when a subclass is created, initializing the shared state.

abstract class Account {
    private double balance;

    Account(double opening) { this.balance = opening; }

    double getBalance() { return balance; }

    void deposit(double amount) { balance += amount; }

    abstract double interestRate();               // differs per account type

    void applyInterest() { balance += balance * interestRate(); }
}

class Savings extends Account {
    Savings(double opening) { super(opening); }
    double interestRate() { return 0.05; }
}

public class Main {
    public static void main(String[] args) {
        Account acc = new Savings(1000);
        acc.deposit(500);
        acc.applyInterest();
        System.out.printf("balance: %.2f%n", acc.getBalance());
    }
}

The balance field, deposit, and applyInterest live in one place. Only the policy that actually varies - interestRate() - is left abstract. A subclass's constructor must call super(...) to initialize that inherited state.

A Gotcha: Mixing abstract and final

abstract and final are opposites. An abstract method demands an override; a final method forbids one. Marking the same thing both ways - or making a final abstract class - is a compile error. Also remember an abstract class can have zero abstract methods: declaring a class abstract purely to stop it being instantiated is legal and sometimes useful for base types you only ever want to extend.

abstract final class Bad { }        // error: abstract and final conflict

abstract class Base {
    abstract final void f();        // error: an abstract method can't be final
}

Abstract Class vs Interface

They overlap, so the choice comes down to what you need to share:

• Abstract class - use it for closely related classes that share state and code. A Savings and a Checking both extend Account, inheriting the balance field and the deposit logic. A class extends only one.
• Interface - use it for a capability unrelated classes can share. A Bird and an Airplane can both be Flyable without sharing any implementation. A class can implement many.

A frequent pattern combines them: an interface defines the contract, and an abstract class implements the boilerplate so concrete subclasses fill in only what is unique.

Next: Polymorphism

Notice that in every example above we held a subclass instance in a variable of the abstract type, then called a method and got the subclass's behavior automatically. That single ability - one reference type, many runtime behaviors - is polymorphism, and it's what makes abstract classes and interfaces pay off. That is the next page.