This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I can think of many business rules, but am unsure as to which I should implement. The specifications say I should not do more than is asked, but there are certain things the specifications "asks" in a manner which it does not explicitly require with a "must".
For instance, the specifications mention that the customer id is an 8 digit number, but it does not qualify that with a "must implement" of any sort. A subtler, yet much larger issue, is as follows:
1. A client locks, retrieves, and unlocks a certain record.
2. A second client locks, retrieves, unlocks, locks, books, unlocks (i.e. retrieves and books ) the same record.
3. The first client still displays the record as vacant, and so, the CSR books the already-booked record... how should the server react?
Unlike the customer id issue, the specifications does not even mention this. Yet this is such a huge issue that it's hard for me to just glaze over. After all, this could easily happen in real life, and a customer is suddenly out of a room. Being so hard to ignore, I implemented did implement this business rule - before booking, I check whether or not the record is vacant (if the 'owner' field is all blanks, as specified), and notify the user with a JOptionPane if it was already booked. Then again, the specifications did indeed not mention this; however, it does explicitly mention that implementing extraneous things may result in point deductions.
What are you guys' thoughts on this whole business rule issue in general, as well as these two specific cases? As always, your help is greatly appreciated!
The instructions clearly say a customer id should be an 8 digit number, so that's what I did. No question about that.
I don't think it's a good thing when 2 customers can book the same room without knowing it from each other. You'll get a double booking, 2 people will show up at the hotel and that's just bad publicity for the company. So that's why I added an extra check to see if a room is still vacant before booking (although that's not in the instructions).
You also have something like the 48 hours rule in the instructions. I ignored that one and justified that decision in my choices.txt
Champ, one of the goals of this certification is to see how you deal with ambiguities and requirements that are not so clear to understand. Regarding the features that have to be made available to the final users, one thing you can do is verify the User Interface section of the instructions that were provided to you. It normally tells you that you must allow the user to search for rooms, given a criteria, and that you must allow the user to book rooms. These are the features that you must provide to your user. The other things are only "musts" that must be followed.
The usage of the locking mechanism is part of a non-functional requirement. You now just have to follow what is asked in the document and there should be no surprises.