Low-Level Design of BookMyShow: Object-Oriented Concepts in Action

Entities and Classes

Based on the use cases, we identify the main entities to be modeled as classes:

• User: Represents customers, admins, or other roles.
• Movie: Stores movie details like title, genre, and duration.
• Theater: Contains theater information, including location and screens.
• Screen: Represents a specific hall within a theater.
• Show: Defines a movie screening at a specific time and screen.
• Seat: Represents individual seats with types like regular or premium.
• Booking: Manages ticket reservations for users.
• Payment: Handles payment transactions.
• Notification: Sends confirmations and reminders.

Relationships Between Classes

The relationships between classes define how they interact:

• A Theater has multiple Screens.
• A Screen contains multiple Seats.
• A Show is associated with one Movie, one Screen, and specific StartTime and EndTime.
• A Booking links a User to a Show and one or more Seats.
• A Payment is tied to a Booking.
• A Notification is sent to a User after a booking or other events.

These relationships ensure that the system’s components work cohesively.

Key Classes and Their Responsibilities

Here’s a detailed look at the key classes and their roles in BookMyShow’s LLD:

• User Class:
  
  
  • Attributes: userId, name, email, phone, role (e.g., customer, admin)
  • Methods: register(), login(), updateProfile(), getBookingHistory()
• Movie Class:
  
  
  • Attributes: movieId, title, genre, language, duration, rating
  • Methods: getDetails(), searchMovies(filter)
• Theater Class:
  
  
  • Attributes: theaterId, name, location, list of screens
  • Methods: addScreen(), removeScreen(), getAvailableShows()
• Screen Class:
  
  
  • Attributes: screenId, theaterId, name, capacity
  • Methods: getSeats(), addSeat()
• Show Class:
  
  
  • Attributes: showId, movieId, theaterId, screenId, startTime, endTime
  • Methods: getAvailableSeats(), bookSeats(seatIds)
• Seat Class:
  
  
  • Attributes: seatId, screenId, seatNumber, type (regular, premium, accessible, recliner), status (available, booked, locked)
  • Methods: lockSeat(), releaseSeat(), confirmBooking()
• Booking Class:
  
  
  • Attributes: bookingId, userId, showId, seatIds, status (pending, confirmed, checked_in, canceled), paymentId
  • Methods: initiateBooking(), confirmBooking(), cancelBooking()
• Payment Class:
  
  
  • Attributes: paymentId, bookingId, amount, status (unpaid, pending, completed, declined, canceled, refunded), method (cash, credit_card)
  • Methods: processPayment(), refund()
• Notification Class:
  
  
  • Attributes: notificationId, userId, message, type (email, SMS), status
  • Methods: sendNotification(), trackStatus()

For hands-on practice with coding such systems, consider our Web Development Course.

Design Patterns Applied

Design patterns provide reusable solutions to common problems in software design. BookMyShow leverages several patterns:

• Singleton Pattern: Ensures a single instance of services like UserService or ConfigurationManager, useful for managing global states.
• Factory Pattern: Creates objects like payment gateways (e.g., PayPal, Stripe) based on user selection.
• Strategy Pattern: Implements different search algorithms (e.g., by city, genre) for flexible filtering.
• Observer Pattern: Notifies users when seats are booked or released, or when a show is about to start.
• Command Pattern: Encapsulates booking actions, enabling undo/redo functionality.
• Adapter Pattern: Integrates third-party payment gateways with the system’s payment service.

For example, the Observer Pattern is critical for seat locking: when a user locks seats, the system notifies other users if those seats become available again.

Database Schema

The database schema for BookMyShow includes tables that map to the main entities: