Class Diagrams

Introduction

A class diagram shows types, fields, methods, and relationships — the static blueprint of your LLD. Interviewers expect you to draw one early: ParkingLot, Vehicle, ParkingSpot, Ticket with clear associations.

Class diagrams answer 'what exists?' before sequence diagrams answer 'what happens when?' Getting relationships wrong (confusing aggregation with reference) signals weak OO modeling.

Learn to draw readable diagrams in under ten minutes with the right level of detail.

Understanding the topic

Key concepts

• Class box: name, attributes, operations (optional in interviews).
• Relationships: association, directed association, inheritance, implementation.
• Multiplicity: one parking lot has many spots (1 — *).
• Role names on associations (customer places order).
• Enums and interfaces shown with stereotype «interface» or italic.
• Package grouping for large domains (billing, inventory).

classDiagram
  class ParkingLot {
    -List~Spot~ spots
    +park(Vehicle) Ticket
    +unpark(Ticket) void
  }
  class Vehicle
  class ParkingSpot
  class Ticket
  ParkingLot --> ParkingSpot
  ParkingLot --> Ticket
  Vehicle --> ParkingSpot

Step-by-step explanation

1. List entities from requirements as candidate classes.
2. Add key attributes only — not every getter.
3. Draw associations with multiplicities.
4. Mark inheritance and interface implementation.
5. Identify composition where lifecycle is owned.
6. Review for God class or missing service layer.

Syntax reference

Sample class diagram notation for parking lot:

• Composition *-- when spots belong to one lot.
• Show return types on methods — interviewers check API clarity.

class ParkingLot {
  -spots: List<ParkingSpot>
  +park(vehicle): Ticket
  +unpark(ticketId): Money
}

class ParkingSpot {
  -id: int
  -type: SpotType
  +occupy(v: Vehicle)
  +release()
}

ParkingLot "1" *-- "many" ParkingSpot
Vehicle --> ParkingSpot : parks at

Informative example

Parking lot class structure matching a typical interview diagram:

public final class ParkingLot {
    private final List<ParkingSpot> spots = new ArrayList<>();
    private final Map<String, Ticket> activeTickets = new HashMap<>();

    public Ticket park(Vehicle vehicle) {
        ParkingSpot spot = findSpot(vehicle.requiredSpotType())
            .orElseThrow(() -> new FullException());
        spot.occupy(vehicle);
        Ticket ticket = Ticket.issue(spot, vehicle);
        activeTickets.put(ticket.id(), ticket);
        return ticket;
    }

    public Money unpark(String ticketId) {
        Ticket ticket = activeTickets.remove(ticketId);
        ticket.spot().release();
        return ticket.calculateFee();
    }

    private Optional<ParkingSpot> findSpot(SpotType type) {
        return spots.stream().filter(s -> s.isFree() && s.supports(type)).findFirst();
    }
}

Diagram classes: ParkingLot, ParkingSpot, Vehicle, Ticket — methods park/unpark match sequence flows.

Real-world use

Real-world applications

• Opening move in parking lot, library, ATM LLD questions.
• Documenting module boundaries in design docs.
• Aligning team on entity names before coding.

Best practices

• Show service classes orchestrating entities.
• Hide private fields if diagram crowded — list public API.
• Use interfaces on diagram when multiple implementations expected.
• Limit to domain-relevant classes only.
• Update diagram when interviewer adds requirement.

Common mistakes

• Database tables only — no behavior methods.
• Bidirectional arrows everywhere without meaning.
• Missing Ticket or Receipt entity for audit trail.
• Too many classes before core flow validated.

Advanced interview questions

Summary

Class diagrams model static OO structure. Include entities, services, enums, interfaces. Mark multiplicities and relationship types. Align class names with Java implementation. Keep interview diagrams focused and readable.