CMD Guide
Home › OO & Low-Level Design

OO Design Problems

Step 7 in the OO & Low-Level Design path · 19 concepts · 0 problems

0 / 19 complete

📘 Learn OO Design Problems from zero

Low-level design rewards a calm, repeatable process far more than memorizing patterns. Here is the expert loop:

  1. Read & restate. Say back what the system does in one sentence and confirm scope with the interviewer. "Design a parking lot" could mean a single garage or a multi-city network — pin it down before drawing anything.
  2. Clarify constraints & requirements. Enumerate the core functional use cases (book a ticket, park a car, post an answer) and explicitly mark non-goals. List the actors and the 3-5 must-have flows. This becomes your checklist and bounds the problem.
  3. Brute-force the model first. Extract nouns as candidate classes and verbs as candidate methods. Write the obvious objects with plain fields and the relationships between them, even if naive. A working object model beats a clever empty one.
  4. Spot the pattern. Re-read your model for the signals above: states & transitions, reactions to events, interchangeable behaviors, varied construction, undoable requests. Apply a pattern only where it removes real if/else sprawl or absorbs anticipated change — patterns are a response to variation, not decoration.
  5. Apply the SOLID principles. Push for single responsibility, composition over inheritance, and programming to interfaces (dependency inversion). Draw the class diagram with explicit relationships — association, aggregation, composition — and the cardinalities.
  6. Edge cases & concurrency. Double-booking, payment failure, capacity overflow, invalid state transitions, and thread-safety on shared managers. Name the concrete mechanism (lock, atomic counter, version check), not just "handle concurrency."
  7. Test by walking a use case. Trace one end-to-end flow through your classes aloud to prove the API hangs together and the methods compose.

Stay narrative — think out loud so the interviewer follows your reasoning. They are scoring your judgment and how you decompose responsibility, not a pixel-perfect UML.

✨ Added by the guide to build intuition — not from the source course.

🎯 Guided practice

Worked example: Design a Movie Ticket Booking System.

  1. Restate & scope. "Users browse movies and showtimes across cinemas, select seats, and pay to book a ticket." Confirm: single city vs. chain, assigned seats vs. general admission, refunds in scope. Assume a chain with assigned seats.
  2. Nouns → classes. Movie, Cinema, CinemaHall (screen), Show, Seat (physical), ShowSeat (a seat bound to one specific show — this is where availability and price live), Booking, Payment, User. Verbs → methods: searchMovies(), getAvailableSeats(), book(), pay(), cancel().
  3. Signal: the booking has states and transitions — Requested → Pending (seats held) → Confirmed → Canceled/Expired. That signal points to a State pattern (or an explicit state machine on Booking) so each transition is validated in one place, not scattered across booleans.
  4. Signal: payment is one of several interchangeable behaviors (credit card, wallet, UPI). That points to a Strategy pattern: a PaymentStrategy interface with concrete implementations chosen at runtime.
  5. The hard signal — concurrency. Two users grabbing the same seat is the crux of this problem. The standard technique is a short-lived seat hold on each ShowSeat with a timeout — e.g., a SeatLockProvider that places a pessimistic lock (or writes a hold row with a 5-minute TTL) before payment, so a second buyer sees the seat as unavailable. Then enforce the commit with a single atomic conditional update on the ShowSeat row (the optimistic-locking version check) so exactly one Booking can flip it to Booked even if two reach the database. Make the payment step idempotent (idempotency key) so a retry never double-charges, and release the hold on timeout.
  6. Signal: notify on events (booking confirmed → email/SMS) → Observer pattern: subscribers register on the booking lifecycle.
  7. Construction & wiring: a BookingService orchestrates the flow; use a Factory for Payment/PaymentStrategy creation, and keep collaborators injected (avoid a hard Singleton) for testability.

Optimal shape: a BookingService that (1) holds the chosen ShowSeats via the lock provider, (2) drives Booking through its state machine, (3) delegates charging to a PaymentStrategy idempotently, (4) on success commits the seats with the atomic version check and notifies observers, and on timeout or failure releases the holds. The teachable insight: the seat-contention signal — not the class list — is what drives the whole design.

✨ Added by the guide — work these before the full problem set.

Lessons in this topic

🧠 Review & recall

Active recall is what moves a topic into long-term memory. Flip each card before revealing, then test yourself — your results are saved on this device.

Flashcard
What is the repeatable expert loop for tackling an OO/low-level design problem in an interview?
tap to reveal →
Read & restate the system in one sentence and confirm scope; clarify requirements/constraints (functional use cases, actors, non-goals); brute-force the object model first (nouns to classes, verbs to methods); spot patterns where they remove if/else sprawl; apply SOLID; cover edge cases & concurrency; then test by walking one use case end-to-end.
💡 Restate, Clarify, Model, Pattern, SOLID, Edge, Test.
Flashcard
How do you extract a first-cut object model from a problem statement?
tap to reveal →
Treat nouns as candidate classes and verbs as candidate methods. Write the obvious objects with plain fields and their relationships even if naive, because a working object model beats a clever empty one.
💡 Nouns = classes, verbs = methods.
Flashcard
In the Movie Ticket Booking design, what is the crux concurrency problem and how is it solved?
tap to reveal →
Two users grabbing the same seat. Place a short-lived seat hold (pessimistic lock or a hold row with a ~5-minute TTL) on each ShowSeat before payment, then commit with a single atomic conditional update (optimistic-locking version check) so exactly one Booking flips the seat to Booked; make payment idempotent via an idempotency key and release the hold on timeout.
💡 Hold with TTL, then atomic version-check commit, idempotent pay.
Flashcard
What is the parking fee model and what spot/vehicle types does the Parking Lot design support?
tap to reveal →
A per-hour model, e.g. $4 for the first hour, $3.5 for the second and third hours, and $2.5 for all remaining hours. ParkingSpot types: Handicapped, Compact, Large, Motorbike, Electric. VehicleType: Car, Truck, Electric, Van, Motorbike. ParkingSpot and Vehicle are abstract base classes with concrete subclasses.
💡 Tiered hourly rate; abstract ParkingSpot/Vehicle with typed subclasses.
Flashcard
How does Stack Overflow's reputation system work and what are its actor roles?
tap to reveal →
Members earn reputation and badges: ten points for an up-vote on an answer and five for an up-vote on a question; higher reputation unlocks privileges like voting, commenting, and editing. Five actors: Admin, Guest, Member, Moderator, System (sends notifications and assigns badges).
💡 Answer +10, question +5; Admin/Guest/Member/Moderator/System.
Flashcard
In the Blackjack design, why does the Hand class track two totals, and what is the dealer's draw rule?
tap to reveal →
An Ace counts as 1 or 11, so a Hand has a soft value (Ace = 11) and a hard value (Ace = 1) — e.g. A+5 is a soft 16 or hard 6. The dealer hits when the hand is 16 or less and stands at 17 or more.
💡 Soft (Ace=11) vs hard (Ace=1); dealer hits ≤16, stands ≥17.
Flashcard
What are the core board/piece classes in the Chess design and the starting piece counts per side?
tap to reveal →
Board is an 8x8 set of Box objects (each Box holds an optional Piece); Piece is an abstract class extended by each piece type; Move records start/end boxes, the player, castling, and any capture; Game tracks moves, current turn, and result. Each side starts with 8 pawns, 2 rooks, 2 bishops, 2 knights, 1 queen, and 1 king.
💡 Board(8x8 Box) + abstract Piece + Move + Game; 8/2/2/2/1/1.
Q1. According to the topic's guidance, when should you apply a design pattern in an OO design problem?
Q2. In the worked Movie Ticket example, which pattern fits modeling a Booking's lifecycle (Requested → Pending → Confirmed → Canceled/Expired)?
Q3. In the Blackjack design, how are a two-card 21 ('blackjack') and any other winning hand paid?
Q4. In the Library Management System requirements, what are the stated limits on borrowing?
Q5. In the Facebook design, how does the extended requirement find connection suggestions for a member?
Q6. Which statement best reflects how the ATM design models a Transaction?