Object-Oriented Design Basics for LLD Interviews

🟢 Low-Level Design · Fresher-friendly → 🟠 senior nuance

Before you can design a parking lot or a chess game in an interview, you need fluency in object-oriented design (OOD) — the art of turning a real-world problem into well-structured classes and objects. Low-Level Design rounds are really just "model this in objects, cleanly." This guide builds the foundation: the four pillars of OOP and, crucially, how objects relate to each other. Nail these and every LLD problem becomes approachable.

Objects and classes

A class is a blueprint; an object is an instance of it. Car is a class; your specific red Tesla is an object. A class bundles state (fields/data) and behaviour (methods) together — that bundling is the whole idea of OOP. In an LLD interview, step one is always: "what are the nouns? Those become my classes."

The four pillars of OOP

🟠 Every OOD conversation rests on these four. Know them cold, with a one-line "why":

• Encapsulation: keep an object's data private and expose only controlled methods. Nobody can put a BankAccount into an invalid state because the balance is only changed through deposit()/withdraw().
• Abstraction: expose what an object does, hide how. You call car.start() without knowing the ignition internals. It tames complexity.
• Inheritance: a subclass inherits a parent's fields/behaviour (Car and Truck both extend Vehicle). Great for reuse — but overused, it creates rigid hierarchies (more below).
• Polymorphism: different objects respond to the same call in their own way. Call shape.area() and a Circle and a Square each compute it correctly. This is what lets code work with an interface, not a concrete type.

The part people underrate: relationships between objects

🟠 Real designs are about how objects connect. Four relationships, and using the right word signals maturity:

The senior rule: favour composition over inheritance

🟠 A classic principle: prefer composition (has-a) over inheritance (is-a). Deep inheritance trees are rigid — a change to a base class ripples everywhere, and "is-a" often doesn't really hold (a Square "is-a" Rectangle famously breaks). Composing behaviour from smaller objects (e.g. a Car has-an Engine) is far more flexible: you can swap the engine without touching a hierarchy. This idea powers most design patterns — and dropping "favour composition over inheritance" in an interview shows real design sense.

How this shows up in an LLD interview

The method: (1) read the requirements and pull out the nouns → candidate classes and verbs → methods; (2) give each class a single, clear responsibility; (3) connect them with the right relationship (has-a vs is-a); (4) program to interfaces/abstractions, not concrete classes, so it's extensible. For "design a parking lot," that yields ParkingLot, Level, Spot, Vehicle (with subtypes), a Ticket — objects with clear roles and relationships. That's OOD in action.

The interview-ready summary

"OOD models a problem as collaborating objects. I rely on the four pillars — encapsulation (hide data behind methods), abstraction (expose what, hide how), inheritance (is-a reuse), and polymorphism (one interface, many behaviours) — and I'm careful with object relationships: association, aggregation, composition, inheritance. My default is to favour composition over inheritance for flexibility, give each class a single responsibility, and program to interfaces. From requirements I extract nouns as classes and verbs as methods." That's the foundation every LLD answer builds on."

What to read next

• SOLID Principles — the five rules for clean OOD
• UML Class Diagrams — how to draw these relationships
• LLD Interview: How to Approach — the step-by-step method
• ← The complete System Design guide (hub)

← LLD interview approach · SOLID principles →