What Are the Four Pillars of OOP in Java?

The four pillars are encapsulation, abstraction, inheritance and polymorphism. Each has a distinct job, and the useful thing is to point at a specific line of code for each rather than reciting definitions.

Encapsulation is about keeping data consistent. The fields are private and the class controls every read and write through its own methods, so an invariant cannot be broken from outside. Abstraction is about hiding how something is done behind a contract: the caller knows what the type promises, not how it delivers. Inheritance is about reusing and specialising: a subclass takes a parent's behaviour and extends or refines it. Polymorphism is what makes the whole thing useful — a single call site can invoke different implementations depending on the runtime type of the object it holds.

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

public class Main {
    public static void main(String[] args) {
        List<Animal> animals = new ArrayList<>();
        animals.add(new Dog("Rex"));
        animals.add(new Cat("Mia"));

        for (Animal animal : animals) {
            System.out.println(animal.describe());
        }
    }
}

abstract class Animal {
    private final String name;              // encapsulation: the field is private

    protected Animal(String name) {
        this.name = name;
    }

    public String getName() {               // encapsulation: controlled access
        return name;
    }

    abstract String sound();                // abstraction: contract, no implementation

    public String describe() {              // polymorphism: the override is chosen at run time
        return getName() + " says " + sound();
    }
}

class Dog extends Animal {                  // inheritance
    Dog(String name) {
        super(name);
    }

    @Override
    String sound() {
        return "woof";
    }
}

class Cat extends Animal {
    Cat(String name) {
        super(name);
    }

    @Override
    String sound() {
        return "meow";
    }
}

The output is two lines — Rex says woof and Mia says meow — and every line of that result was decided by one pillar. The call site animal.describe() knows nothing about dogs or cats; that is polymorphism. The sound method is a promise the abstract class makes, which is abstraction. The private name with a getter is encapsulation. And Dog and Cat exist only because Animal could be inherited.

They answer different questions. Abstraction is about design: what does this type promise, and what can a caller rely on without knowing the internals? Encapsulation is about implementation: how is the state protected so it stays valid?

The clearest way to separate them is to ask what each one does to the caller. Abstraction removes the need to know how. A caller who uses a List does not need to know that it is backed by an array. Encapsulation removes the ability to break the rules. A caller who writes directly to a field cannot corrupt the object's invariants, because the field is private and the setter validates the input.

They are independent. A class can be fully encapsulated and barely abstracted — a simple value holder with private fields and getters and setters exposes exactly as much as it needs to. It can also be highly abstracted and poorly encapsulated: an interface that promises void process() hides the implementation, but if the implementing class exposes its internal buffer as a public field, the abstraction leaks.

public class Main {
    public static void main(String[] args) {
        // Abstraction: the caller depends on the interface, not the class.
        Storage store = new InMemoryStore();

        // Encapsulation: the class controls every read and write.
        store.put("alpha", 1);
        System.out.println("read back : " + store.get("alpha"));
        System.out.println("missing  : " + store.get("beta"));

        // The caller cannot put the store into an invalid state.
        try {
            store.put("gamma", -5);
        } catch (IllegalArgumentException e) {
            System.out.println("rejected : " + e.getMessage());
        }
        System.out.println("size     : " + store.size());
    }
}

interface Storage {
    void put(String key, int value);

    int get(String key);

    int size();
}

class InMemoryStore implements Storage {
    private final java.util.Map<String, Integer> values = new java.util.HashMap<>();

    @Override
    public void put(String key, int value) {
        if (value < 0) {
            throw new IllegalArgumentException("value cannot be negative: " + value);
        }
        values.put(key, value);
    }

    @Override
    public int get(String key) {
        return values.getOrDefault(key, 0);
    }

    @Override
    public int size() {
        return values.size();
    }
}

Where they reinforce each other is the usual case: an abstract base class declares the contract, and the concrete subclasses encapsulate the state needed to satisfy it. The Animal example on this page is that shape — the abstract sound method is the abstraction, the private name with a getter is the encapsulation.

A useful heuristic for an interview: if you would be happy to change the implementation without touching any caller, you have abstraction. If you would be happy to add a validation rule without touching any caller, you have encapsulation.

Here is a small class that shows both ideas working together — the public method is the abstraction, the private field plus the getter is the encapsulation:

Because object-orientation in Java is about how the language models data and behaviour, not about whether every single value in the program is an object. Java's model is that you organise behaviour into classes, that objects hold state and expose behaviour, and that you can substitute one implementation for another through a common type. Primitives and static members are pragmatic exceptions inside that model, not a rejection of it.

Primitives exist for performance and footprint. A field of type int is stored inline in the object rather than as a reference to a boxed Integer on the heap, which removes an allocation and a pointer chase from every numeric operation. The autoboxing machinery bridges the two worlds so that a primitive can still be put into a generic collection or passed to a method that expects an object.

Static members exist because some things genuinely belong to a type rather than to an instance: a constant, a factory method, a pure utility function, a shared registry. The introduction of static methods on interfaces made that more natural, since a utility function could live next to the contract it implements without needing a separate class.

The design position is that the language is object-oriented with pragmatic escape hatches, not that it forbids them. The telling detail is that the escape hatches are opt-in and explicit: you write the static keyword, and you box a primitive yourself or let the compiler do it. Nothing about the object model is compromised, because an object-oriented program can still be built entirely from classes and instances — it simply does not have to use an object for every value.