OOP Fundamentals¶

Prerequisites: none beyond basic class syntax.

← Low-Level Design | Next: SOLID Principles →

Why This Exists¶

Every LLD candidate can define "encapsulation" as "hiding data." Almost none can look at a ParkingSpot class with a public is_occupied field being set directly from three different places and say that's the encapsulation violation costing you the interview. The definitions are not the skill. The skill is recognizing the violation in code you're about to write, before the interviewer has to point it out.

Classes & Objects¶

A class is a blueprint; an object is a specific instance with its own state. The interview-relevant nuance: decide what state an object owns, and refuse to let other objects mutate it directly.

class ParkingSpot:
    def __init__(self, spot_id: str, size: str):
        self.spot_id = spot_id
        self.size = size
        self._occupied_by: "Vehicle | None" = None

    def is_free(self) -> bool:
        return self._occupied_by is None

    def occupy(self, vehicle: "Vehicle") -> None:
        if not self.is_free():
            raise ValueError(f"Spot {self.spot_id} already occupied")
        self._occupied_by = vehicle

    def vacate(self) -> None:
        self._occupied_by = None

Nothing outside ParkingSpot sets _occupied_by directly. That single decision is most of what "good OOP" means in an LLD interview — not the vocabulary.

Encapsulation¶

Bundling data with the methods that are allowed to change it, and refusing direct external mutation of internal state. The interview tell: a leading underscore or a property is not encapsulation by itself — encapsulation is real when every state transition goes through a method that can enforce an invariant.

class BankAccount:
    def __init__(self, balance: float = 0):
        self._balance = balance          # not directly settable from outside

    @property
    def balance(self) -> float:
        return self._balance

    def withdraw(self, amount: float) -> None:
        if amount > self._balance:
            raise ValueError("Insufficient funds")   # invariant enforced here
        self._balance -= amount

Abstraction¶

Exposing what an object does, hiding how. The caller depends on a small, stable interface; the implementation can change freely behind it.

from abc import ABC, abstractmethod

class PaymentMethod(ABC):
    @abstractmethod
    def pay(self, amount: float) -> bool:
        """Attempt payment; return True on success."""

class CreditCardPayment(PaymentMethod):
    def pay(self, amount: float) -> bool:
        # talk to card network, handle decline, etc. — caller doesn't know or care
        return True

class UpiPayment(PaymentMethod):
    def pay(self, amount: float) -> bool:
        return True

ExitGate calls payment_method.pay(amount) — it never branches on if isinstance(payment_method, CreditCardPayment). That branch, if you write it, is the signal to an interviewer that abstraction hasn't actually happened yet; it's just been renamed.

Inheritance¶

An is-a relationship: Car is-a Vehicle. Use it when the subtype genuinely is a more specific version of the supertype and should be substitutable wherever the supertype is expected (see SOLID's Liskov Substitution Principle).

class Vehicle(ABC):
    def __init__(self, license_plate: str):
        self.license_plate = license_plate

    @abstractmethod
    def spot_size_required(self) -> str: ...

class Car(Vehicle):
    def spot_size_required(self) -> str:
        return "medium"

class Motorcycle(Vehicle):
    def spot_size_required(self) -> str:
        return "small"

Polymorphism¶

The same call — vehicle.spot_size_required() — resolves to different behavior depending on the concrete type, and the calling code never needs a type check to get there.

def find_spot(vehicle: Vehicle, spots: list[ParkingSpot]) -> ParkingSpot | None:
    required = vehicle.spot_size_required()   # polymorphic call
    for spot in spots:
        if spot.size == required and spot.is_free():
            return spot
    return None

Add a Truck subclass tomorrow and find_spot does not change — this is the payoff, and it's the same payoff Open/Closed (SOLID) is built on.

Composition vs. Inheritance¶

flowchart TB
    subgraph Inherit["Inheritance — is-a"]
        V["Vehicle"] --> C["Car"]
        V --> M["Motorcycle"]
    end
    subgraph Compose["Composition — has-a"]
        EC["ElectricCar"] -->|has a| CH["ChargingCapability"]
        EC -->|has a| ENG["Engine"]
    end

The interview default: favor composition. Reach for inheritance only when the relationship is a genuine, stable is-a that will not need to vary at runtime. "Car has an Engine" survives requirements changes; "Car is-an Engine" is nonsensical, and the equivalent nonsense shows up constantly in real designs as inheritance chosen for code reuse rather than for a true taxonomy.

class ChargingCapability:
    def charge(self, kwh: float) -> None: ...

class ElectricCar(Vehicle):
    def __init__(self, license_plate: str, charger: ChargingCapability):
        super().__init__(license_plate)
        self.charger = charger          # composition: has-a

    def spot_size_required(self) -> str:
        return "medium"

Trade-offs¶

Interview Questions¶

Key Takeaways¶

Previous: Low-Level Design | Next: SOLID Principles