I am supposed to write a simple Cinema Booking System, which allows a customer to make reservations for movies.
The Cinema consists or different theatres, with different amount of seats, price and movie showtimes.
The user should be able to input his name and other credentials and then make reservations for 1 or more movies and seats.
When he is finished booking, the system should output a receipt, listing his name, the movie(s) the showtime(s) and reservation number.
I have tried to follow the OOP-principles as best to my current capabilities.
The classes I’ve set up would be the following:
- CinemaBooking -> entrypoint into programm
- Room -> receives its seating size via [row] [col]
- Movie -> has movietitle, shwotime, the room and a price.
- Customer -> shoud store any user info like name , email and phone and generate
booking number
I am a bit unsure on where to put the user-i/o in this case: Shoud it remain within CinemaBooking, or should i generate a seperate class which only does the I/O?
Or should I just move the whole I/O stuff to another class (e.g. the Customer Class)?
There are many advises to be given, I’ll give only most important.
First, the main idea of OOP was to suit real world, so it’s better to make your classes as close to real objects as possible.
Create class Booking which will be just equivalent of a ticket, not an entry point for a program. I.e. it will contain information about user, theatre, seat and cost.
Create class Theatre which will contain number of seats (not rows x cols – some seats may be reserved, some may be broken, and some theatres just haven’t squared structure). Alternatively, since one Theatre can have several rooms, you can create class Room, which will have property “seats”, and then add Rooms to Theatre.
Also create class Movie. Movies and Theates/Rooms will ref each other: Movie will contain list of Theatres it is showed in, and Theatre will have list of Movies it shows.
Then create class Seance, which will contain time and movie.
Create class Customer only in case you will work with this customer later and want to save his attributes (name, history of bookings, etc.). Otherwise it makes no sense to create one more class.
This is your model. Classes may very a bit, but if you got core idea, this won’t be a problem.
Second, create class BookingSystem which will summarize functionality of all previous classes. It will be an implementation of Facade design pattern, and it really simplifies access to your booking subsystem.
Third, create separate class for I/O work. Never put I/O work to the model classes. Imagine, that your cinema booking system will be the part of another system with it’s own I/O – you will need to redesign all your code to receive data from higher layers. So, just make separate class for user’s input and program’s output.
And this will be your view.
Finally, create main program class. You can give it same name the program have itself of something like that. This one will just control program flow from view to models and back. So, this part is called controller, and overall idea is known as Model-View-Controller pattern.