AlgoMaster Logo
AlgoMasterDesign Travel Booking Systemmedium

Design Travel Booking System

medium

A trip is a flight, a hotel room and a car, booked as one action. Each booking system issues its own confirmation numbers and keeps its own records. The facade turns three calls into one and remembers which confirmations belong to the current trip.

Implement the TravelBookingFacade class:

  • TravelBookingFacade() creates a facade with no trip booked.
  • String[] bookTrip(String destination, String checkIn, String checkOut) books a flight for checkIn, reserves a room for the stay and rents a car for the stay. It returns "--- Booking trip to <destination> ---", the three lines the booking systems gave back, and "--- Trip booked! ---". While a trip is already booked it changes nothing and returns ["--- Trip already booked ---"].
  • String[] cancelTrip() cancels all three bookings and returns "--- Cancelling trip ---", the three lines, and "--- Trip cancelled ---". With no trip booked it changes nothing and returns ["--- No trip to cancel ---"].
  • String bookFlightDirect(String destination, String date), String reserveRoomDirect(String destination, String checkIn, String checkOut) and String rentCarDirect(String location, String pickupDate, String returnDate) each place one booking on their own and return the line that system gave back. A booking made this way is not part of any trip.
  • String tripSummary() returns "Trip to <destination> | <flightId> | <hotelId> | <carId>", or "NO TRIP" when nothing is booked.
  • String bookingReport() returns "Flights: <n> | Hotels: <n> | Cars: <n>" counting the bookings each system still holds.
  • int tripCount() returns how many trips have been booked.

Confirmation numbers come from the booking systems. Flights count up from FL-1001, rooms from HT-2001 and cars from CR-3001, and every booking takes the next number in its sequence whether it came from bookTrip or from a direct call.

The booking systems report themselves with fixed wording:

  • "Flight: Booked to <destination> on <date>. Confirmation: <id>" and "Flight: Cancelled booking <id>."
  • "Hotel: Reserved in <destination> from <checkIn> to <checkOut>. Confirmation: <id>" and "Hotel: Cancelled reservation <id>."
  • "Car: Rented in <location> from <pickupDate> to <returnDate>. Confirmation: <id>" and "Car: Cancelled rental <id>."

The supporting FlightBooking, HotelReservation and CarRental types, along with the public FacadeDriver test harness, are already implemented in the starter code. Implement only TravelBookingFacade; it must obtain confirmation numbers from those provided booking systems. The examples use FacadeDriver operations because that is the class the tests instantiate.

Example 1:

Input:

Output:

Explanation: One call reaches all three booking systems. Each one issues the first number in its own sequence, and the summary reads back what the facade recorded.

Example 2:

Input:

Output:

Explanation: Cancelling walks the same three systems in the same order. Every booking is released, so the report drops to zero and there is no trip left to describe.

Constraints

  • 1 <= destination.length <= 20
  • Dates are strings in the form YYYY-MM-DD.
  • At most 100 calls in total are made across all methods.

Starter Code

Only TravelBookingFacade is unfinished. The supporting subsystem types and FacadeDriver test harness are pre-implemented; do not modify them.

How the design is graded

needs 7/10 to pass
  • One call, three booking systems

    Full marks when `bookTrip` calls the flight, hotel and car systems in that order, collects what each returned, and `cancelTrip` undoes all three. Lose points heavily when the facade writes the booking lines itself or leaves one subsystem out of either method.

  • Confirmations belong to the subsystems

    Full marks when each confirmation number is issued by the subsystem that made the booking and read back from it, so a booking made outside a trip takes its place in the same sequence. Lose points heavily when the facade keeps its own counters and builds the identifiers itself.

  • Structure and naming

    Full marks when `bookingReport` counts what the subsystems still hold, a second `bookTrip` is refused while a trip is active, cancelling twice reports nothing to cancel, and cancelling a trip leaves bookings made outside it alone. Lose points for printing to stdout.

Passing every test is not enough on its own. A submission is accepted only when the design also clears the bar.

Hints

Loading...
CallReturns
new FacadeDriver()null
bookTrip("Paris", "2025-06-01", "2025-06-07")["--- Booking trip to Paris ---","Flight: Booked to Paris on 2025-06-01. Confirmation: FL-1001","Hotel: Reserved in Paris from 2025-06-01 to 2025-06-07. Confirmation: HT-2001","Car: Rented in Paris from 2025-06-01 to 2025-06-07. Confirmation: CR-3001","--- Trip booked! ---"]
tripSummary()"Trip to Paris | FL-1001 | HT-2001 | CR-3001"
bookingReport()"Flights: 1 | Hotels: 1 | Cars: 1"
tripCount()1

One call reaches all three booking systems. Each one issues the first number in its own sequence, and the summary reads back what the facade recorded.

Run checks these cases. Submit also runs a larger hidden set.