Need advice on proper class design

Question

Hi all,

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)

I really hope my question is comprehensible. Help would be greatly appreciated.

regards el.

Answer 1

Write toString() methods on all the classes. Worry about the I/O later. Get the relationships right first. I/O is the least of your worries.

Answer 2

Whenever I make class, it has following in it:-

1. All instance variables set to private.

2. Implement getters and setters.

3. Implement toString() method.

If you are using Eclipse then it will help you to implement these methods automatically. Just write instance variables, right click in editor -> Source -> Generate getters and setters.

Answer 3

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.

Answer 4

Actually, ticket will not contain info about user theatre seat or cost. It will contain references to other objects: User, Theater, Seat Cost.

You will need o0ne "manager" type class that will hold the rest of the program: BookingApp which has a main() could be it. I agree don't worry so much about interface for now - but DO NOT print to the terminal from Domain classes. Use toString() to test the object content, but the main() method should call getters on the other classes and create the output. Very bad idea and form to have domain classes writing directly to the UI. So, you have Theatre, User, Seat, Ticket, Price. Consider dependencies. Seat is tied to theatre and price is based on theatre and seat, I assume. Start with the Things, and draw lines between them to show how they will communicate or reference each other. For example, given a User, find all their tickets - from ticket find seat and from seat find theatre. Then add the attributes (private as JavaGeek said). Start small. Maybe just Theatres and Seats. Get that to work then add the next class. Add to your design incrementally and iteratively. DO NOT try and write and compile the whole thing at once. I suggest Peter Coad's Java Design book ( very cheap and very good) as a good intro to java design.