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.