OOP Principles

What is Object-Oriented Programming?

Object-Oriented Programming (OOP) is a way of organising code around objects — entities that combine related data (fields) and behaviour (methods) in a single unit. Instead of writing a program as a long sequence of instructions that manipulate separate variables, OOP lets you model the real world: a BankAccount knows its own balance and knows how to deposit or withdraw. A User knows its own credentials and knows how to authenticate.

The problem OOP solves: as programs grow, procedural code — variables here, functions there, no clear ownership of data — becomes impossible to reason about. Who is allowed to change this value? Which function is responsible for this logic? OOP answers both questions by keeping data and the code that operates on it together, in one place, with controlled access.

// Procedural style: data and logic are separate, no ownership
            String  accountId = "ACC-001";
            double balance    = 500.0;
            
            // Anyone can corrupt state — no rules, no guarantees
            balance = -9999;
            
            double calculateInterest(double bal, double rate) { return bal * rate; }
            void   printBalance(double bal)              { System.out.println(bal); }
            
            // OOP style: data + behaviour bundled, access controlled
            public class BankAccount {
                private final String id;
                private       double balance;
            
                public void deposit(double amount) {
                    if (amount <= 0) throw new IllegalArgumentException("Must be positive");
                    balance += amount;  // only THIS class can modify balance
                }
            
                public double calculateInterest(double rate) { return balance * rate; }
                public void   printBalance() { System.out.println(balance); }
            }

Java is OOP-first: every piece of code lives inside a class. There are no standalone functions, no global variables. The four fundamental principles that make OOP work — encapsulation, inheritance, polymorphism, and abstraction — are not just theoretical concepts. They are the design rules that separate maintainable production code from a codebase nobody wants to touch.

The Four Pillars at a Glance

OOP organises code around objects — entities that bundle state (fields) and behaviour (methods). Java is OOP-first: every piece of code lives inside a class, and the JVM runs nothing that isn't part of an object graph.

1. Encapsulation

Encapsulation means an object controls its own state. External code cannot put the object into an invalid state because it has no direct access to the fields — only to the methods that enforce the rules.

// ❌ No encapsulation — anyone can corrupt the state
public class BankAccountBad {
    public double balance;
    public String accountNumber;
}
account.balance = -1_000_000;  // perfectly legal, completely wrong
account.accountNumber = null;  // now the account has no identity

// ✅ Encapsulated — object enforces its own invariants
public class BankAccount {
    private final String accountNumber;
    private       double balance;
    private final List<String> history = new ArrayList<>();

    public BankAccount(String number) {
        if (number == null || number.length() != 10)
            throw new IllegalArgumentException("Invalid account number");
        this.accountNumber = number;
    }

    public double getBalance() { return balance; }

    public void deposit(double amount) {
        if (amount <= 0) throw new IllegalArgumentException("Must be positive");
        balance += amount;
        history.add("DEPOSIT $" + amount);
    }

    public void withdraw(double amount) {
        if (amount > balance) throw new IllegalStateException("Insufficient funds");
        balance -= amount;
        history.add("WITHDRAW $" + amount);
    }

    // Defensive copy — caller cannot mutate our internal list
    public List<String> getHistory() { return List.copyOf(history); }
}

// All fields private+final, constructor, accessors, equals, hashCode, toString — generated
record Money(BigDecimal amount, Currency currency) {
    // Compact constructor for validation
    Money {
        if (amount.compareTo(BigDecimal.ZERO) < 0)
            throw new IllegalArgumentException("Negative money");
    }
}

2. Inheritance

Inheritance lets a class reuse and specialise the behaviour of another class via extends. Java allows only single class inheritance (to avoid the diamond problem) but unlimited interface implementation.

/*
 *  Inheritance hierarchy:
 *
 *           Animal (base)
 *          /      \
 *        Dog      Cat
 *        |
 *     Labrador (most specific)
 *
 *  Every Labrador IS-A Dog IS-A Animal.
 *  Each level adds/overrides behaviour.
 */

public class Animal {
    protected final String name;

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

    public void eat() { System.out.println(name + " eating"); }

    // Override hook — subclasses provide the sound
    public void makeSound() { System.out.println(name + " makes a sound"); }
}

public class Dog extends Animal {
    private final String breed;

    public Dog(String name, String breed) {
        super(name);   // super() must be the first call
        this.breed = breed;
    }

    @Override               // Always annotate — compiler catches typos
    public void makeSound() { System.out.println(name + " barks"); }

    public void fetch() { System.out.println(name + " fetches!"); }
}

Dog dog = new Dog("Rex", "Labrador");
dog.eat();        // inherited from Animal
dog.makeSound();  // Dog's override: "Rex barks"
dog.fetch();      // Dog's own method

// ❌ Stack "is not really a List" — extending ArrayList exposes add(index, e),
// remove(index), subList()… none of which a stack should have
public class Stack extends ArrayList { ... }

// ✅ Stack "has a" list internally — only exposes push/pop/peek
public class Stack<T> {
    private final Deque<T> elements = new ArrayDeque<>();
    public void push(T item) { elements.push(item); }
    public    T pop()        { return elements.pop(); }
    public    T peek()       { return elements.peek(); }
}

3. Polymorphism

Polymorphism means the same method call produces different behaviour depending on the actual runtime type of the object. It comes in two flavours:

• Runtime (dynamic dispatch) — method overriding, resolved by the JVM via vtable lookup at runtime. This is the powerful one.
• Compile-time (static dispatch) — method overloading, resolved by the compiler based on argument types.

Runtime polymorphism — the vtable

public abstract class Shape {
    public abstract double area();       // each subclass provides its own
    public String describe() {
        return String.format("Area: %.2f", area());
    }
}

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

public class Rectangle extends Shape {
    private final double w, h;
    public Rectangle(double w, double h) { this.w = w; this.h = h; }
    @Override public double area() { return w * h; }
}

// This method works for Circle, Rectangle, and any future Shape —
// no changes required when new subclasses are added (Open/Closed Principle)
public double totalArea(List<Shape> shapes) {
    return shapes.stream()
                 .mapToDouble(Shape::area)  // runtime dispatch for each element
                 .sum();
}

/*
 *  HOW the JVM picks the right method (vtable):
 *
 *  Shape s = new Circle(5.0);
 *  s.area();  ← which implementation?
 *
 *  Circle object on heap:
 *  ┌────────────────────────────┐
 *  │ class pointer → Circle ───┼──► Circle vtable:
 *  │ r: 5.0                    │      area()     ─► Circle.area()   ✅
 *  └────────────────────────────┘      describe() ─► Shape.describe()
 *
 *  The reference type (Shape) is irrelevant at runtime.
 *  The OBJECT's class determines which method runs.
 */

Polymorphism in real production code

// Interface = the contract. Implementations can change without touching callers.
public interface PaymentProcessor {
    void process(BigDecimal amount);
}

// Spring injects the right implementation based on profile/config
@Service
public class OrderService {
    private final PaymentProcessor processor;  // program to interface

    public OrderService(PaymentProcessor processor) {
        this.processor = processor;
    }

    public void checkout(Order order) {
        processor.process(order.total());  // no idea WHICH processor — doesn't need to know
    }
}

@Profile("production") @Component
public class StripeProcessor implements PaymentProcessor { ... }

@Profile("test")       @Component
public class MockProcessor  implements PaymentProcessor { ... }

// Adding a new payment provider = new class, zero changes to OrderService

4. Abstraction

Abstraction defines what something does without revealing how. Java provides two tools: interfaces (pure contracts) and abstract classes (partial implementation + contract).

Interface vs abstract class — when to use each

Template Method pattern with abstract class

// Abstract class defines the ALGORITHM SKELETON
public abstract class DataExporter {

    // Template method — final so subclasses can't break the flow
    public final void export(List<?> data) {
        validate(data);
        String formatted = format(data);   // abstract — subclass decides format
        write(formatted);                  // abstract — subclass decides destination
    }

    protected void validate(List<?> data) {
        if (data == null || data.isEmpty())
            throw new IllegalArgumentException("No data to export");
    }

    protected abstract String format(List<?> data);
    protected abstract void   write(String content);
}

// Concrete subclasses provide the HOW
public class CsvExporter extends DataExporter {
    @Override
    protected String format(List<?> data) { return /* CSV logic */ ""; }
    @Override
    protected void   write(String content)  { /* write to file */ }
}

public class JsonApiExporter extends DataExporter {
    @Override
    protected String format(List<?> data) { return /* JSON logic */ ""; }
    @Override
    protected void   write(String content)  { /* POST to API */ }
}

OOP Under the JVM Hood

Understanding the JVM's object model helps you reason about performance and debug subtle bugs.

Object memory layout

/*
 *  Dog dog = new Dog("Rex", "Labrador");  (Dog extends Animal)
 *
 *  ┌──────────────────────────────────────┐
 *  │          Dog Object (heap)           │
 *  ├──────────────────────────────────────┤
 *  │ Object header (12-16 bytes)          │
 *  │   mark word  — hashCode, GC, locks  │
 *  │   class ptr  → Dog.class (vtable)   │
 *  ├──────────────────────────────────────┤
 *  │ Animal fields (inherited, laid first)│
 *  │   name: ref → "Rex" (String on heap) │
 *  ├──────────────────────────────────────┤
 *  │ Dog fields                           │
 *  │   breed: ref → "Labrador"           │
 *  └──────────────────────────────────────┘
 *
 *  Field access is O(1) regardless of inheritance depth —
 *  offsets are computed at class-load time, not runtime.
 */

The Collections Framework as a masterclass in OOP

// ABSTRACTION: interface defines the contract
List<String> names;            // declare as interface type — always

// POLYMORPHISM: swap implementations without touching callers
names = new ArrayList<>();   // O(1) random access
names = new LinkedList<>();  // O(1) head/tail insertion
names = new CopyOnWriteArrayList<>(); // thread-safe reads

// ENCAPSULATION: internal array is hidden; you interact via the API
names.add("Alice");  // no idea if the array is resizing right now — don't care

// INHERITANCE: AbstractList provides shared implementation (iterator, indexOf, etc.)
// ArrayList extends AbstractList implements List — 2-level hierarchy, flat and clear

Common Pitfalls

// "A Square is a Rectangle" — sounds right, breaks code
class Square extends Rectangle {
    @Override public void setWidth(int w)  { super.width = w; super.height = w; }
    @Override public void setHeight(int h) { super.width = h; super.height = h; }
}

Rectangle r = new Square();
r.setWidth(5); r.setHeight(10);
r.getArea();   // Expected 50, got 100 — violated caller's assumptions

// ✅ Fix: don't use inheritance here; both implement a common interface
interface Shape { int getArea(); }
class Rectangle implements Shape { ... }
class Square    implements Shape { ... }

class Dog extends Animal {
    public void eats() { ... }  // typo! creates a NEW method, doesn't override eat()
}
Animal dog = new Dog();
dog.eat();  // calls Animal.eat() — our method is never reached

// ✅ @Override makes the compiler catch this immediately
@Override
public void eats() { }  // compile error: does not override any method

// ❌ Type-checking in a loop means the type hierarchy isn't doing its job
for (Shape s : shapes) {
    if (s instanceof Circle)    { render((Circle) s); }
    else if (s instanceof Rectangle) { render((Rectangle) s); }
}

// ✅ Polymorphism: move render() to the Shape hierarchy
for (Shape s : shapes) { s.render(); }  // each shape knows how to render itself

// ✅ OR — Java 21 pattern matching in switch (sealed types)
String desc = switch (shape) {
    case Circle    c -> "circle r="  + c.radius();
    case Rectangle r -> "rect "     + r.w() + "x" + r.h();
};

Interview Questions