What Are the Four Pillars of OOP?

Yes, and the interesting part is showing where each pillar lives rather than naming them. Abstraction is the Storage interface: it states what a report can do with a store without saying how the store works. Encapsulation is the private list inside MemoryStorage: the outside world can only call save and count. Inheritance is DailyReport extending Report to reuse the storage handling. Polymorphism is the line where a Storage reference holds a MemoryStorage object and the runtime picks the right implementation.

public class Main {
    public static void main(String[] args) {
        Storage store = new MemoryStorage();
        DailyReport report = new DailyReport(store);
        report.saveAll("monday", "tuesday");
        System.out.println("saved = " + report.savedCount());
    }
}

interface Storage {
    void save(String text);
    int count();
}

class MemoryStorage implements Storage {
    private final java.util.List<String> items = new java.util.ArrayList<>();
    public void save(String text) { items.add(text); }
    public int count() { return items.size(); }
}

class Report {
    protected final Storage storage;
    Report(Storage storage) { this.storage = storage; }
    void save(String text) { storage.save(text); }
    int savedCount() { return storage.count(); }
}

class DailyReport extends Report {
    DailyReport(Storage storage) { super(storage); }
    void saveAll(String... texts) { for (String t : texts) { save(t); } }
}

Notice the two-way benefit. The abstract interface lets the report be written against any store, including a database-backed one, with no change to the report class. The encapsulation lets the storage swap its internal list for a map without touching the report. Inheritance gives DailyReport the storage plumbing for free, and polymorphism means the program never has to ask which report implementation it is holding.

One honest caveat: this example is compact, not realistic. In production code you would not extend Report to add a daily flavour, you would compose. The four pillars are still worth demonstrating because interviewers want to see you know how the mechanisms line up, and because abstraction plus polymorphism are what actually pay the bills at scale.

Encapsulation solves the problem of unauthorised change. Data is bundled with the operations allowed to touch it, and the internals are hidden behind access modifiers, so the class stays in charge of its own consistency.

Abstraction solves the problem of irrelevant detail. A caller depends on what a type promises to do, not on how it does it, which keeps the two free to change independently and keeps the caller's understanding small.

Inheritance solves the problem of repeated structure. A subclass reuses and specialises a parent's behaviour, which promotes reuse when the relationship really is an is-a relationship.

Polymorphism solves the problem of conditional logic scattered across call sites. One reference can hold different implementations, and the runtime picks the right behaviour, so new implementations do not require editing the code that uses them.

There is a useful angle for an interview: encapsulation and abstraction protect and simplify, while inheritance and polymorphism enable reuse and variation. A candidate who can only recite the list usually cannot say which problem each pillar solves, and that is the part that actually matters when you are designing something.

They get confused because both are often described as hiding something, and both are usually implemented with the same tools: private fields and public methods. The difference is what is hidden and from whom.

Encapsulation hides data. It is about protecting state that lives inside an object. The state is still there, still real, and the class simply refuses to let anyone else touch it directly, which is what allows the class to guarantee things like a non-negative balance or a consistent cache.

Abstraction hides complexity. It is about the relationship between a caller and a collaborator. The complexity may live anywhere, including in a completely different class, and the caller is shielded from it because it depends on a narrow contract instead of a wide implementation.

A concrete pair makes the distinction stick. A Money class whose constructor rejects negative amounts is using encapsulation to protect an invariant. A PaymentGateway interface that hides whether the payment is going to a sandbox, a third-party API or a fake test double is using abstraction to hide complexity.

They reinforce each other, and a good answer says so. Encapsulation without abstraction leaves callers coupled to your internals. Abstraction without encapsulation exposes state that the implementation needs to protect. Used together, they let you change the inside of a component without touching the code that uses it.