The Four Pillars of OOP — Encapsulation, Inheritance, Polymorphism, Abstraction

Object-Oriented Programming is just a way of organising code around objects — and an object is a self-contained unit that holds its own data along with the behaviour that works on that data. In Java, a class is the blueprint, and an object is what you get when you create — or instantiate — that class. So if I have a Dog class with name and breed as fields and bark() and eat() as methods, every dog object I create from it has the same shape but its own values.

The four pillars — Encapsulation, Inheritance, Polymorphism, and Abstraction — are the design principles that govern how you build those objects so the system stays maintainable as it grows.

Encapsulation is about giving the class control over its own state. The fields stay private, and the only way to change them is through the methods the class exposes. So instead of letting the caller do setBalance(getBalance() - 100), the BankAccount class offers account.withdraw(100) — and inside that method it validates the amount, checks for overdraft, logs the transaction, and updates the balance. The caller doesn't know how the balance is stored. If I change balance from double to BigDecimal later for precision, no caller breaks, because they never touched the field directly. That's what encapsulation buys you — it isolates change.

Inheritance is the IS-A relationship between classes, expressed through the extends keyword. Dog extends Animal means a Dog is an Animal — it inherits the parent's fields and methods, can override behaviour, and can add its own. Before reaching for it, I run the IS-A test: a dog is an animal, so inheritance fits; but a car has an engine, so that's composition, not inheritance. Java only allows single inheritance through classes — you can't extends two parents — and the reason is the diamond problem, where two parents could provide conflicting versions of the same method. For multiple inheritance, you use interfaces.

Polymorphism literally means 'many forms' — the same method call behaves differently depending on the actual object. There are two kinds. Compile-time polymorphism is method overloading: same method name, different parameters, and the compiler picks the right version at build time. Runtime polymorphism is method overriding — Shape s = new Circle(); s.area() runs Circle.area(), because the JVM looks at the actual object type at runtime, not at the type of the variable. Without polymorphism, adding a new payment method means editing every if-else chain; with it, you just add a new class.

Abstraction is hiding the implementation details and exposing only what the caller needs. An interface is full abstraction — pure contract, no implementation detail. An abstract class is partial — it can mix abstract methods with concrete ones. The everyday version of abstraction is writing List names = new ArrayList<>() instead of ArrayList names = new ArrayList<>(). By depending on the List contract, you can swap to LinkedList tomorrow and zero callers change.

The four work as a system, not a checklist. Encapsulation is what makes polymorphism safe — because the class controls its own invariants, you can substitute one implementation for another without breaking callers. Abstraction is what tells you where inheritance boundaries should be. And that one line, List names = new ArrayList<>(), actually uses all four at once: List is the abstraction, ArrayList's internal array is encapsulated, any List implementation can substitute via polymorphism, and ArrayList satisfies the List contract through inheritance.