The Four Pillars of OOP with Examples

1. Encapsulation — hide the state

Keep data private and expose behaviour instead. The point is not secrecy; it is that invariants can be enforced in one place. If the balance field is public, any line in the codebase can make it negative. If it is private, only the class can change it — and the class can refuse.

public class Account {
    private long balancePaise;               // nobody outside can touch it

    public void withdraw(long amount) {
        if (amount <= 0) throw new IllegalArgumentException("amount must be positive");
        if (amount > balancePaise) throw new InsufficientFundsException();
        balancePaise -= amount;              // the only path that can change it
    }

    public long balancePaise() { return balancePaise; }
}

2. Abstraction — hide the mechanism

Encapsulation hides data; abstraction hides how. Callers depend on a contract — an interface — and stay unaffected when the implementation behind it changes. That is what makes a payment provider swappable and a class testable with a fake.

interface PaymentGateway {
    PaymentResult charge(long amountPaise, Card card);
}

class RazorpayGateway implements PaymentGateway { /* HTTP calls */ }
class FakeGateway     implements PaymentGateway { /* used in tests */ }

class Checkout {
    private final PaymentGateway gateway;      // the contract, not the class

    Checkout(PaymentGateway gateway) { this.gateway = gateway; }
}

3. Inheritance — reuse a type

A subclass gets the parent's fields and methods, and can add or override. The valuable part is not code reuse — it is that the subclass is the parent type, so anything accepting the parent accepts it.

The test is the Liskov Substitution Principle: any place the parent works, the child must work too. The textbook violation is Square extends Rectangle — code that sets width and height independently and checks the area breaks the moment a Square is passed in, because a square cannot honour that behaviour.

4. Polymorphism — one call, many behaviours

The same call dispatches to different implementations depending on the actual object. It is what lets you delete a chain of ifs and add a new case by adding a class.

abstract class Notification {
    abstract void send(String to, String body);
}

class EmailNotification extends Notification { void send(String t, String b) { /* SMTP  */ } }
class SmsNotification   extends Notification { void send(String t, String b) { /* gateway */ } }
class PushNotification  extends Notification { void send(String t, String b) { /* FCM    */ } }

// The caller never branches on type - a new channel needs no change here
void notifyAll(List<Notification> channels, String to, String body) {
    for (Notification n : channels) n.send(to, body);
}