This has helped me identify classes and some design. Great and some logic also for the system.
However, for a use case such as Make reservation, I have no idea how to accomplish it. I need to know what existing reservations there are. e.d single rooms available for July12th.
SingleRoomsAvailable(dates) and doubleRoomsAvailable(dates). I have looked at some MVC material and this is what I'm attempting to do, I think. The above classes are the model. I'm not too concerned with the view, but the controller is my problem, again I think.
The view will provide me with Customer, dates and room types. These are sent to control, lets call it Booking system, Booking system, checks availability of rooms for dates, then customer can create a reservation object with reserveLines for each date-room pair and writes the reservation to file and writes the reserveLine to file.
So, Does the Booking system interacts with rooms via hotel file and get room info, then
The booking system interacts with booked rooms via reserveLine data file and gets booked room info for dates.
The booking system will also need to interact with reservation file and customer file to get a reservation for a customer.
Booking system's responsibilies Getavailablerooms(). Getreservation(). GetCustomer(). It seems a lot for one class to cover.
From these responsibilies, I can makereserve(), cancelreserve() checkin()
As always thanks for reading, as I can imagine how frustrating "and LONG" this is to read for you guys.
I have ordered Martin fowler Object Primer, as OO concepts are proving a little more complicated than expected or else I'm a little dumber than I thought. Any other advice on reading would be appreciated. I kinda feel I have a lot more reading to do to make the next step, but what to read up on??

Some potential flaws that will lead you astray and into an untenable design:

1. Room is a single. Room is a double. -- if you intend to implement this as inheritance (Room IS A Double, Room IS A Single), then this will be wrong. Whether a room is single or double should probably be an attribute of Room, say "OccupancyType" or something like that

2. Customers -> Makereserve and cancelreserve. These are not the responsibilities of a Customer, even though it's what a real-world customer would do. In fact, you have to ask whether it is the customer who actually does the making and canceling of reservations in a hotel reservation system. Take a hint from the names... it tells you the class to which the Make and Cancel operations should be assigned.

3. Reception is a customer. Again, you are falling into the trap of trying to model your classes too closely to the real world. Object-orientation is not so much about modeling the real world as it is about assigning responsibilities to the correct classes. The classes you come up with may or may not be somewhat similar to real-world objects but often they are really abstractions of actions and relationships that are not exactly like they are in the real world.

4. Manager is a receptionist. If you are thinking inheritance here, then it's wrong. This will be an incorrect crossing of two separate roles: the Manager role and the Receptionist role. Rather, a User of your system can accomplish tasks interesting to a Manager or tasks that are interesting to a Receptionist.

I strongly encourage to develop your design incrementally and in a Test-Driven manner. If you do Test-Driven Development properly, you will get to see the interactions between classes more clearly and see if production code will make sense and if it can be maintained and extended easily. You can also refactor your design as you go and discover more details about the interactions and relationships you want to model in code.

Booking system should not be a class in your application. The application is the booking system (a system is a collection of things that work together to accomplish work)

SingleRoomsAvailable(dates) and DoubleRoomsAvailable(dates) is smelly. What happens when you want to expand your hotel to have Suites and Penthouses? A more resilient design would be getAvailableRooms(type, dates) where type is Single, Double, etc. If you add room types later, you won't have to write new methods for them to check their availability.

At some point, you will come to realize that there is a category of classes generally referred to as "Services" or "Business Services" -- these services will interact with Model objects like Reservation, Room, Customer, etc.

Yes, there is a lot of reading to do. For TDD, I usually recommend "Growing Object-Oriented Software, Guided by Tests"

Eamon Nixon
Greenhorn

Joined: Jun 30, 2012
Posts: 10

posted Jul 25, 2012 16:24:48

0

Junilu Lacar wrote:

2. Customers -> Makereserve and cancelreserve. These are not the responsibilities of a Customer, even though it's what a real-world customer would do. In fact, you have to ask whether it is the customer who actually does the making and canceling of reservations in a hotel reservation system. Take a hint from the names... it tells you the class to which the Make and Cancel operations should be assigned.

I see what you mean, a customer probably has only create, set, get methods.

Junilu Lacar wrote: 3. Reception is a customer. Again, you are falling into the trap of trying to model your classes too closely to the real world. Object-orientation is not so much about modeling the real world as it is about assigning responsibilities to the correct classes. The classes you come up with may or may not be somewhat similar to real-world objects but often they are really abstractions of actions and relationships that are not exactly like they are in the real world.

So basically so far, I have identified a few of the likely classes in the system. Customer, room, reservation, hotel. Manager, receptionist are possibilinties.
Find reservations, this should be the responsibility of reserve class.
Find customers, this should be the responsibility of ???.
Find rooms, this should be the responsibility of ???.
Find room price, room responsibility.
Now, I should list data requests like this and see who could answer those requests. Find cheapest room, I will have to find all room objects and then get the lowest for the room.getprice().

Junilu Lacar wrote: 4. Manager is a receptionist. If you are thinking inheritance here, then it's wrong. This will be an incorrect crossing of two separate roles: the Manager role and the Receptionist role. Rather, a User of your system can accomplish tasks interesting to a Manager or tasks that are interesting to a Receptionist.

Interesting to a manager, I have not come across this before. Do you mean like Print to file will be a common method, so it should be an interface.

Junilu Lacar wrote: I strongly encourage to develop your design incrementally and in a Test-Driven manner. If you do Test-Driven Development properly, you will get to see the interactions between classes more clearly and see if production code will make sense and if it can be maintained and extended easily. You can also refactor your design as you go and discover more details about the interactions and relationships you want to model in code.

Test-Driven is agile. Write your tests first. TDD would make a lot of sense and seems logical. "It all works perfectly on paper, so it must have been implemented incorrectly". And also, puts huge pressure on designers. "Mail Order a bride" is another pillar of TDD, I was promised everything and she doesn't know how to use a toilet.
Thanks for the book reference, I probably read more than code is my problem. Once I start coding, I stop all else and force squares into circles. "It works" Stupid approach I know.

Thanks for the advice and help. I see a lot clearer know. Customer class should be Customer Data. Sets and Gets methods. Hotel class. Hotel Data. Sets and Gets.
reservation class. Room objects, date, Customer object. Gets() Sets()
Reserve class. reservation object. cancel add remove.
RoomReserve class. room objects. reservation objects. getBooked(type,dates) getAvailable(type,dates) getAllRooms() The idea is data and responsibility grouping, so an object is fully equipped to survive alone. The object has its data and uses its data simply. Kinda like name and serial number, it cant do much damage if it doesn't know too much about anything else.
Thanks also Junilu for not explicitly correcting my mistakes, as I would have gained nothing from that. I especially appreciate that extra effort on your behalf.

Eamon Nixon wrote:Interesting to a manager, I have not come across this before. Do you mean like Print to file will be a common method, so it should be an interface.

Nothing at all to do with anything like Print to File...should be an interface. That's a bit of a stretch of the imagination there, BTW; not really sure what your line of thinking is to get from Print being a common service to making it into an interface. Rather, I meant interesting as in:

As a Manager, I would like to see how many rooms are occupied so I can plan how many staff members I need for the night shift.

or

As a Receptionist, I would like to check the availability of Single Occupancy Rooms so I can answer a customer inquiry over the phone.

These are things that users in these roles would be interested in getting from the booking system and they can be translated into a design with various classes, attributes, and responsibilities.