General Considerations: Maximum=58 Deductions=0
Actual=58 Documentation: Maximum=20 Deductions=0
Actual=20 GUI: Maximum=24 Deductions=13 Actual=11 Server: Maximum=53 Deductions=0 Actual=53 Total: Maximum=155 Deductions=13
Certification Score=142
Like I said I was shocked on the GUI. I recognize that I'm mainly a J2EE developer, but the 13 point deduction hurts.
Oh well at least I did not lose points anywhere else.
On the locking mechanism I used a lock class to keep track of the locks. The Lock class used a HashSet as the data structure since I only needed to stored the record number or -1. I did not store any information about a client id.
According to the directions we were to create a DataClient class that has all the public methods of the Data class. This includes the unlock, lock, write methods. Since we gave the DataClient access to these methods, I felt we had to assume a good intentioned client to a certain extent. Most people that justify using a client id give the example of a client trying to unlock a record that is currently held by a second client. That is great to be concerned about that issue, but what prevents a malicious client from modifying a record to have bogus information?
The fact is that we code the DataClient. So we ensure that a record will be locked, modified, and then unlocked in the appropriate sequence.
In my project I tried to follow the "kiss" rule. We were developing an application that could be understood by a junior level developer.
Mark, when I saw a previous post by you I realized that I need not worry about more advanced details. You helped convince me to design a simple application with no more than what was in the requirements. No storing of customer's names for booking a flight, etc.
Maybe it hurt me on the gui to keep it simple or maybe it was just my lack of Swing exposure.
Again thanks to everyone who has contributed to this site.