The Bus Management System applies object-oriented principles extensively. Encapsulation is shown by wrapping data and methods inside classes such as Passenger, Ticket, Bus, and BusCompany. Inheritance isn't explicitly used here, but polymorphism and abstraction can be indirectly noted in class constructions and methods like bookSeat and getStatus, which manage and display encapsulated state. Moreover, modular interaction is evident through methods like addBus, bookSeat, and findPassenger, fostering loose coupling and high cohesion, core traits of object-oriented design .

The process begins with starting the program and creating a bus company named CityLine. The user is prompted to enter a bus number and capacity, which are used to create a Bus object. This bus is then added to the company using the addBus() method. For each passenger, the user must enter their name and age, which are used to create a Passenger object. The bookSeat(passenger) method attempts to book the seat; if successful, a Ticket and a Booking are added to the bus. The total number of booked seats is found using getBookedSeats(). Users can search for passengers by name through the findPassenger(name) method. The showAllBuses() method displays the status of all buses. The program ends after these operations .

To extend the system with route management, a new Route class could be introduced to encapsulate route details such as starting point, destination, and intermediate stops. This class could be associated with each Bus. For dynamic pricing, a PricingStrategy interface could define methods for determining ticket prices based on factors such as demand, time, or route length. Bus could utilize this interface to dynamically calculate costs during ticket booking. Additional methods like updateRoute() in BusCompany could manage route changes, and applyPricing() could adjust fares in Booking or Ticket. A database layer or configuration files might store routing and pricing data for persistence .

The current system model heavily relies on user input at several stages, such as entering bus details, passenger information, and querying bookings. While this interactivity can be useful for tailored input, it may not scale efficiently with larger data or multiple buses. To optimize, the process could leverage batch processing or preloaded data for bus and passenger setup, reducing real-time input dependency. An improved GUI or form-based input could streamline interactions, allowing users to input data simultaneously rather than via sequential prompts .

The Bus class uses the bookSeat(Passenger p) method for seat booking. It checks if the current number of bookings is less than the bus's capacity. If a seat is available, it creates a Ticket object with the bus number and passenger information, then adds a new Booking consisting of the Passenger and Ticket to the bus's list of bookings. If the bus is full, it outputs a message indicating that no booking can be made for the passenger. This demonstrates both object creation (Passenger, Ticket, Booking) and adherence to capacity constraints .

The Ticket class ensures unique ticket identification using a static integer counter that starts at 1000. Each time a Ticket object is instantiated, the constructor increments the counter and assigns its value to the ticketNumber of the new Ticket, ensuring that every ticket has a unique number. This unique identifier is used in conjunction with the bus number and passenger details to represent each ticket .

Using a static ticket counter for generating ticket numbers implies that ticket numbers remain unique across all instances of the system. This can be beneficial, ensuring no duplication as the counter increments globally for every Ticket created. However, in real-world applications, particularly those distributed or managing numerous buses across different services or systems, a centralized mechanism might be needed to reset or adjust this counter, potentially requiring persistence layers or unique identifiers incorporating additional context like service date or bus route .

The Passenger class effectively employs encapsulation by making its fields private and providing public accessor methods (getName, getAge) to interact with those fields. This design encapsulates the data, controlling access and modifications, thus enhancing security and data integrity. The use of a toString() method for representation also adds practical utility, enabling direct logging and output that are human-readable. However, further methods for data validation or additional encapsulated attributes could enhance its robustness for broader applications .

The status of all buses is checked and displayed using the showAllBuses() method of the BusCompany class. This method iterates over the list of buses owned by the company, calling the getStatus() method for each bus. The getStatus() method in the Bus class returns a string showing the bus number, its capacity, and the current number of booked seats .

The findPassenger() method in the Bus class searches through the list of bookings to find a passenger by name. It iterates over the bookings, accessing each Booking's Passenger and comparing their name to the provided search term using equalsIgnoreCase(). If a match is found, it returns the Passenger object; otherwise, it returns null. This linear search approach serves effectively within the context of potentially small collections of bookings per bus .