Class Diagram Interview Patterns and Variations

LLD interviews test your ability to translate requirements into clean class structures. Here are common patterns and variations you'll encounter, with strategies for each.
Common Interview Questions:
"Design a Parking Lot system" (tests composition, inheritance, state management)
"Design a Library Management System" (tests associations, multiplicity, lifecycle)
"Design an Elevator System" (tests state pattern, concurrency considerations)
"Design a Vending Machine" (tests state pattern, inventory management)
"Add payment processing to your design" (tests Strategy pattern integration)
Pattern 1: Hierarchical Modeling (Parking Lot)
Vehicle
+ getSize(): VehicleSize
+ getType(): VehicleType
Motorcycle
Car
Truck
Interview Trap: Candidates often create separate spot types (MotorcycleSpot, CarSpot, TruckSpot). Instead, use a single ParkingSpot with a spotSize attribute and validation logic. This follows the Open-Closed Principle (OCP) - adding new vehicle types doesn't require new spot classes.
Pattern 2: State Management (Vending Machine)
«interface»
VendingState
+ insertCoin(): void
+ selectProduct(): void
+ dispense(): void
IdleState
HasMoneyState
DispensingState
Key Decision: Use State pattern (interface + implementations) rather than enum with switch statements. This makes adding new states trivial and avoids violating OCP. Each state class encapsulates its own behavior.
Pattern 3: Strategy Injection (Payment Processing)
PaymentProcessor
- strategy: PaymentStrategy
+ processPayment(amount): Receipt
+ setStrategy(strategy): void
◇
«interface»
PaymentStrategy
+ pay(amount): Receipt
Interview Question: "How would you add UPI payment?" With Strategy pattern, you simply create UPIPayment implements PaymentStrategy without modifying existing code. This demonstrates OCP in practice.
Multiplicity Notation:
1 - Exactly one (every Car has exactly one Engine)
0..1 - Zero or one (ParkingSpot has zero or one Vehicle)
* or 0..* - Zero or more (Library has zero or more Books)
1..* - One or more (Order must have one or more LineItems)
2..5 - Specific range (Elevator serves 2 to 5 floors)
Example: In a Library, the relationship between Library and Book is 1..* (one library has one or more books), while Member to Book is 0..* (a member can borrow zero or more books).
Common Variations and Follow-Ups:
"Add pricing tiers": Use Strategy or Chain of Responsibility (HourlyRate, FlatRate, PeakHourRate)
"Handle concurrency": Note thread-safety needs in diagram (synchronized methods) but don't model locks directly
"Support notifications": Add Observer pattern (ParkingLot notifies Observers when spots become available)
"Add persistence": Introduce Repository pattern (ParkingLotRepository interface with implementations for database/cache)
Interview Tip: When the interviewer says "Now add feature X," don't redraw the entire diagram. Circle the affected classes, draw new classes separately, and explain how they integrate. This shows you can extend designs without breaking existing structure (OCP).
Machine Coding Considerations:
Start simple: Draw core classes first (Vehicle, ParkingSpot, ParkingLot). Add patterns later
Validate early: Before coding, walk through a scenario ("Car enters, finds spot, parks, pays, exits") using your diagram
Think SOLID: Each class should have one reason to change. If ParkingLot handles payments, fees, and spot assignment, split it
Avoid premature optimization: Don't add caching, thread pools, or database indexes in the initial design unless asked
Red Flags to Avoid: First, God classes that do everything (ParkingLotManager with 30 methods). Second, circular dependencies (Vehicle references ParkingSpot which references Vehicle). Third, deep inheritance (Vehicle → MotorVehicle → FourWheeler → Car is unnecessary). Fourth, missing abstractions (hardcoding payment logic instead of using Strategy). If the interviewer points out any of these, acknowledge and refactor immediately.

💡 Key Takeaways

✓Common patterns: Hierarchical modeling (Vehicle inheritance), State management (Vending Machine), Strategy injection (Payment)

✓Use single ParkingSpot class with size validation instead of separate spot types per vehicle (follows OCP)

✓Multiplicity notation: 1 (exactly one), 0..1 (optional), * (zero or more), 1..* (one or more), n..m (range)

✓When adding features, extend design without modifying existing classes (demonstrate OCP in practice)

✓Avoid God classes, circular dependencies, deep inheritance, and missing abstractions

📌 Examples

1Parking Lot: Single ParkingSpot class with size attribute instead of MotorcycleSpot/CarSpot/TruckSpot classes

2Vending Machine: State pattern with IdleState, HasMoneyState, DispensingState instead of enum with switch

3Payment: Strategy pattern allows adding UPI payment without modifying PaymentProcessor class

4Library: Member borrows Books (0..* multiplicity) and Library contains Books (1..* multiplicity)

← Back to Class Diagrams Overview