Grokking the Object Oriented Design Interview

Vote

0% completed

Design a Parking Lot

On This Page

System Requirements

Use case diagram

Building the design in five stages

Stage 1: the vehicles and the spots

Stage 2: a floor that can find a free spot

Stage 3: the ticket, the rate and the payment

Stage 4: the lot that ties it together

Stage 5: the panels the driver touches

The finished class diagram

The patterns in this design

What we left out, and what to say about it

Let's make an object-oriented design for a multi-floor parking lot.

A parking lot or car park is a dedicated cleared area that is intended for parking vehicles. In most countries where cars are a major mode of transportation, parking lots are a feature of every city and suburban area. Shopping malls, sports stadiums, megachurches, and similar venues often feature parking lots over large areas.

System Requirements

We will focus on the following set of requirements while designing the parking lot:

The parking lot should have multiple floors where customers can park their cars.
The parking lot should have multiple entry and exit points.
Customers can collect a parking ticket from the entry points and can pay the parking fee at the exit points on their way out.
Customers can pay the tickets at the automated exit panel or to the parking attendant.
Customers can pay via both cash and credit cards.
Customers should also be able to pay the parking fee at the customer's info portal on each floor. If the customer has paid at the info portal, they don't have to pay at the exit.
The system should not allow more vehicles than the maximum capacity of the parking lot. If the parking is full, the system should be able to show a message at the entrance panel and on the parking display board on the ground floor.
Each parking floor will have many parking spots. The system should support multiple types of parking spots such as Compact, Large, Handicapped, Motorcycle, etc.
The Parking lot should have some parking spots specified for electric cars. These spots should have an electric panel through which customers can pay and charge their vehicles.
The system should support parking for different types of vehicles like car, truck, van, motorcycle, etc.
Each parking floor should have a display board showing any free parking spot for each spot type.
The system should support a per-hour parking fee model. For example, customers have to pay $4 for the first hour, $3.5 for the second and third hours, and $2.5 for all the remaining hours.

Use case diagram

Here are the main Actors in our system:

Admin: Mainly responsible for adding and modifying parking floors, parking spots, entrance, and exit panels, adding/removing parking attendants, etc.
Customer: All customers can get a parking ticket and pay for it.
Parking attendant: Parking attendants can do all the activities on the customer's behalf, and can take cash for ticket payment.
System: To display messages on different info panels, as well as assigning and removing a vehicle from a parking spot.

Here are the top use cases for Parking Lot:

Add/Remove/Edit parking floor: To add, remove or modify a parking floor from the system. Each floor can have its own display board to show free parking spots.
Add/Remove/Edit parking spot: To add, remove or modify a parking spot on a parking floor.
Add/Remove a parking attendant: To add or remove a parking attendant from the system.
Take ticket: To provide customers with a new parking ticket when entering the parking lot.
Scan ticket: To scan a ticket to find out the total charge.
Credit card payment: To pay the ticket fee with credit card.
Cash payment: To pay the parking ticket through cash.
Add/Modify parking rate: To allow admin to add or modify the hourly parking rate.

Building the design in five stages

The rest of this lesson builds the design one stage at a time. Each stage adds a few classes and ends with something the system can do that it could not do before.

This is the order to use in an interview. It gives you a working slice early, and it means that if you run out of time you stop with something that works rather than with half a diagram.

Stage	What it adds	What works after it
1	Vehicles and spots	You can ask whether a vehicle fits a spot
2	Floors and the display board	A floor can find a free spot
3	Tickets, rates and payment	A stay can be priced and paid for
4	The lot itself	A car can enter, park and leave
5	Entrance, exit and info panels	The flow runs through real devices

The code compiles and runs in Python, Java and C++. Reading the stages in order gives you the whole program.

Each stage below also adds its classes to one diagram. The classes from earlier stages stay exactly where they were, drawn in grey, so the picture fills in as the build goes on. By the last stage you have seen a reason for every box in the finished diagram.

Stage 1: the vehicles and the spots

Start with the two things the whole product is about. A vehicle arrives, and a spot holds it.

Nothing can be parked yet. What this stage gives you is the rule that decides which spots a given vehicle may use, and that rule is the most important part of the design. Keeping it on Vehicle means adding a new vehicle type never forces a change in the parking lot.

Enums and constants: the fixed sets the design refers to:

Requirements 8 and 10 name the spot types and the vehicle types, and those two requirements produce every class in this stage. The diagram shows two small inheritance trees and one arrow between them: a spot holds at most one vehicle, which is the association written as holds 0..1. The hollow triangle is inheritance, and it points at the parent. The legend after the diagram shows how to read every arrow used in this lesson.

Python3

. . . .

ParkingSpot: a spot knows its number, its type, and whether it is free. The five subclasses exist because the class diagram names them, and they carry no behaviour of their own beyond the type they pass up. Only ElectricSpot adds anything, because it owns the panel a driver uses to charge:

Python3

. . . .

Vehicle: each vehicle knows which spot types it fits in, best fit first. A motorbike takes a motorbike spot. A truck or a van needs a large spot. An electric car prefers an electric spot and will settle for a compact or large one:

Python3

. . . .

Stage 2: a floor that can find a free spot

Now put the spots somewhere. A floor holds spots and answers one question: is there a free spot that this vehicle fits in?

After this stage the system can find and assign a spot, and report how many of each type are left.

ParkingDisplayBoard: the board holds a count per spot type. Counting is more reliable than tracking one example free spot per type, which has to be recalculated every time that one spot fills:

Requirements 1, 8 and 11 produce the two classes added here. Both new arrows are composition, the filled diamond: a floor owns its spots and its display board, because deleting the floor deletes them. Compare that with holds from stage 1, where a spot only refers to a vehicle that exists on its own.

Python3

. . . .

ParkingFloor: one map of every spot, plus an index by type. A single map per type would mean five maps and a five way branch in every method that touches them, and a sixth spot type would mean editing all of it:

Python3

. . . .

Stage 3: the ticket, the rate and the payment

A driver needs something that proves when they arrived, and the lot needs a way to turn that into money.

The important decision here is that the ticket holds a reference to the actual spot. Without it there is no way to find the vehicle at the exit, and counting occupied spots is not enough.

ParkingTicket, ParkingRate and Payment: the rate card is requirement 12, and payment covers the cash and card cases from requirement 5:

Requirements 3, 5 and 12 produce the money classes. The ticket points at the vehicle and the spot with plain arrows, association rather than ownership, because a ticket does not own a car. Payment is abstract with one subclass per way of paying, which is inheritance passing the substitution test: both subclasses really can be asked to take money.

Python3

. . . .

Paying for a parking ticket: here are the steps a customer goes through. Every one of them is covered by the three classes above:

Stage 4: the lot that ties it together

This is the stage where the whole flow works. A car arrives, gets a real spot and a ticket, and later pays and leaves.

Two details are worth saying out loud. The lot is a singleton, because there is one car park, and handing out a spot has to run one caller at a time so that two entrances cannot be given the same spot.

Account, Admin and ParkingAttendant: the people who operate the lot:

Requirement 7 and the actor list produce this stage. The lot owns its floors and its rate card, so the filled diamonds sit at the lot. The people connect with plain arrows: an admin configures the lot and an attendant processes tickets through it, but neither owns anything.

Python3

. . . .

ParkingLot: it finds a floor with a suitable free spot, issues the ticket, prices the stay on the way out, and releases the spot once the ticket is paid:

Python3

. . . .

Stage 5: the panels the driver touches

The last stage is the devices. None of them hold logic of their own. They call the lot, which is what keeps the rules in one place.

EntrancePanel, ExitPanel, CustomerInfoPortal and ElectricPanel: the entrance panel prints a ticket, the exit panel scans it and takes payment, the info portal on each floor settles a ticket early so nothing is owed at the exit, and the electric panel bills for charging:

Requirements 2, 4, 6 and 9 produce the panels. The lot owns the entrance and exit panels, so those two arrows are composition. The customer info portal is different: the lot keeps no list of portals, so the portal only refers to the lot, which is a plain association. The electric panel belongs to its electric spot, the one composition in the design that is drawn at a spot.

Python3

. . . .

The finished class diagram

Now that every class exists, here is the whole model in one picture. It is the same picture the five stages have been filling in, with every class in full colour at last: nothing on it appears here for the first time.

Here are the main classes of our Parking Lot System:

ParkingLot: The central part of the organization for which this software has been designed. It has attributes like 'Name' to distinguish it from any other parking lots and 'Address' to define its location.
ParkingFloor: The parking lot will have many parking floors.
ParkingSpot: Each parking floor will have many parking spots. Our system will support different parking spots 1) Handicapped, 2) Compact, 3) Large, 4) Motorcycle, and 5) Electric.
Account: We will have two types of accounts in the system: one for an Admin, and the other for a parking attendant.
Parking ticket: This class will encapsulate a parking ticket. Customers will take a ticket when they enter the parking lot.
Vehicle: Vehicles will be parked in the parking spots. Our system will support different types of vehicles 1) Car, 2) Truck, 3) Electric, 4) Van and 5) Motorcycle.
EntrancePanel and ExitPanel: EntrancePanel will print tickets, and ExitPanel will facilitate payment of the ticket fee.
Payment: This class will be responsible for making payments. The system will support credit card and cash transactions.
ParkingRate: This class will keep track of the hourly parking rates. It will specify a dollar amount for each hour. For example, for a two hour parking ticket, this class will define the cost for the first and the second hour.
ParkingDisplayBoard: Each parking floor will have a display board to show available parking spots for each spot type. This class will be responsible for displaying the latest availability of free parking spots to the customers.
ParkingAttendant: This class encapsulates the operations an attendant can perform, which is taking a payment on a customer's behalf. It is an Account, like Admin, because an attendant signs in.
CustomerInfoPortal: This class will encapsulate the info portal that customers use to pay for the parking ticket. Once paid, the info portal will update the ticket to keep track of the payment.
ElectricPanel: Customers will use the electric panels to pay and charge their electric vehicles.

The patterns in this design

Singleton. ParkingLot allows one instance, and get_instance is where that is enforced. Expect an interviewer to push back on this one harder than on any other pattern, because a singleton is a global by another name: it makes two lots impossible to run in one test, and it hides a dependency inside every class that reaches for it.

Nothing else here is a named pattern. Payment with a cash and a card subclass is an abstract base class, and the five spot types are plain inheritance. Calling those Strategy would be stretching the word. The test is whether an object holds the behaviour and can swap it, and nothing here does.

What we left out, and what to say about it

This design covers the twelve requirements and nothing else. Reservations ahead of arrival, season tickets, number plate recognition and refunds are all absent, and that was a decision rather than an oversight.

Two places where a reviewer will question the design, and the honest answer to each:

The five spot subclasses carry no behaviour. They are here because the class diagram names them. A single ParkingSpot with a type field would do the same work, and adding a sixth type would then be one new enum constant.
ParkingLot does two jobs. It finds spots and it issues tickets. Those are two reasons to change, so a longer design would split them.

💡 In the interview: build in this order and say what each stage gives you before you write it. When you reach the ticket, say why it holds a spot rather than a count, because that single choice is what makes the exit flow possible. Expect two follow ups. The first is "what if pricing changes", which is the strategy pattern behind ParkingRate. The second is "what if two cars arrive at the same instant", which is why issuing a ticket takes a lock.

Mark as Completed

Kushak Zohaad Jafry

· 7 months ago

Issues I found with this design:

1. Unnecessary Inheritance for ParkingSpot

The code creates separate classes (HandicappedSpot, CompactSpot, LargeSpot, etc.) that literally do nothing except pass an enum to the parent constructor. This violates "composition over inheritance."

java

// Current approach - 5 classes doing the same thing
public class CompactSpot extends ParkingSpot {
    public CompactSpot() {
        super(ParkingSpotType.COMPACT);
    }
}

// Better approach - single class with composition
public class ParkingSpot {
    private String number;
    private ParkingSpotType type;
    private boolean free;
    
    public ParkingSpot(String number, ParkingSpotType type) {
        this.number = number;
        this.type = type;
        this.free = true;

Show 2 replies

Heinz Yeo

· 3 years ago

Show 1 reply

George

· 3 years ago

· 4 years ago

archit chauhan

· 3 years ago

Mithran Daniel

· 2 years ago

abhijeetdixit11

· a year ago

On This Page

System Requirements

Use case diagram

Building the design in five stages

Stage 1: the vehicles and the spots

Stage 2: a floor that can find a free spot

Stage 3: the ticket, the rate and the payment

Stage 4: the lot that ties it together

Stage 5: the panels the driver touches

The finished class diagram

The patterns in this design

What we left out, and what to say about it