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.
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.
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.
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.
Campbell Ritchie wrote:Welcome to the Ranch
You should be learning Java and design in parallel. You cant do advanced Java without something to program and you cant program anything unless you have designed it.
I agree with John McClellan that you are over thinking this problem. You should develop it incrementally. Designing it in terms of sending a message to find which rooms are available” is not part of the basic design, but an implementation detail, which you can work out later. Getting a list of available rooms is not necessarily part of the booking process. Getting, “Yes, we can accommodate four people from 18th July until 21st July is.
Stop thinking in terms of programming. think how you would model a reservation for a particular room from 18th to 21st July on paper. Then think how that can be programmed. The more you do on paper, the easier the programming task will be.
Start with a room, and decided what its attributes are. Probably number of beds and some way of relating the guest to dates. You may not need any more for a room at this stage. Get that working. Then adding the rooms to make up a hotel is an enhancement of what you already have. Remember number of rooms is an attribute of a hotel. You can have hotels with 25 rooms or 250 rooms.
John McClellan wrote:In a way you're thinking of it in excessively technical terms. Don't. You're also trying to copycat over from a different (thought slightly similar) problem. Don't.
Basically the whole idea behind using objects is to be able to model the problem in your code instinctively and naturally, much like it is in the natural world. If you're trying to come up with a class model or something in some really technical way for a very simple, natural problem like this, then you're not thinking about objects instinctively and naturally enough.
As for trying to pull from a library example, doing stuff like that is really more for learning a language or an API or something; it isn't something you want to do very much when going from one problem space to another. Admittedly it can be a good idea sometimes, but imagine the difference in the real world between checking out a book in a library and renting a room at a hotel. They're a little bit similar, but still pretty different. So in the real world, if you managed a library and started managing a hotel, you might take a few good ideas with you, but you wouldn't want to get too obsessed with using a really similar technique. Kind of the same idea here.
Campbell Ritchie wrote:
Disagree.Anayonkar Shivalkar wrote: . . . That is, your classpath should contain parent directory of dotcombust (instead of dotcombust itself). . . .
It is usually best not to set a system classpath at all, but some applications set it for you while you aren’t watching. QuickTime is notorious for doing that. Delete the references to dotcom, test project and the jdk from the classpath. They should not be in a system classpath. If you need a classpath, you should set it with the -cp tags. If you are at the dotcom stage, you don’t yet need to know about -cp. Change your classpath to readNote the .; at the beginning. That will take you to your “current” directory as a default, which is what you usually want.CLASSPATH=.;C:\Program Files\Java\jre6\lib\ext\QTJava.zip
You will have to navigate to the correct directory for dotcom. I would suggest you //comment out the package names from all your dotcom classes and use the directory they are in as an unnamed package.