UrlyBird Questions

[Tim Sparg]

Hi guys

I've got a couple of questions about the UrlyBird assignment that I'm hoping that somebody can clarify.

I don't quite understand the delete flag, if a record has the delete flag set should we ignore?
Also with regard to the delete flag should a user be able to delete a record?


And I presume we only ever edit records, not actually add or delete them?
So in that case can we get away with only ever editing the owner field?


The 48 hour rule, should we put a property into the system telling the system what the date currently is?
This would allow the examiner to change the date, and thus check that we where implementing the rule

[Roel De Nijs]

Hi Tim,

1/ A record with the "deleted" flag set to true (or deleted), should be considered as non-existing, so indeed it should be ignored. Deleting a record from the client is not a required functional requirement, so it's not needed to implement (although you can add it to your application). I didn't implement it myself

2/ According to the specifications the only 2 required actions are finding rooms and booking a room (which is considered an update of the room record). Of course you should make sure that the update-method of your Data class is capable of updating all fields.

3/ A property into the system to tell the current date I think the system knows the current date (new Date();, System.currentTimeInMillis();,...). I didn't implement the 48-hours rule because it was not a must requirement (and of course I documented in my choices.txt why I didn't implemented this rule)

Kind regards,
Roel

[edit] this was actually my 2500th post

[Tim Sparg]

Hi Roel


With regard to the date - I was thinking of setting a custom system date for the front end(independent of new Date() etc etc). Ie the examiner would be able to change the date, and check that his selection of available rooms changed.
However as you say it is not a must requirement, so I think I will just leave it out


Thanks for the speedy response
Tim

[Greg Funston]

Roel: 2/ According to the specifications the only 2 required actions are finding rooms and booking a room (which is considered an update of the room record).

I have two questions regarding this.

1. The assignment states that owner is "(an 8 digit number) of the customer who has booked this. Note: that for this application, you should assume that customers and CSRs know their customer ids." Up until now I have seen no GUIs with the capacity to input the OWNER value and I have not built it into my GUI yet. I expect to book a room that we must (change the flag, and update the owner) in the database file during the update method.

and

2. Do we need to have a delete button and a create button in the GUI?

[Roel De Nijs]

1/ if you do not build an input field into your gui, how will a CSR have to enter the customer id?

2/ Not needed, because searching and booking are the only required actions

[Greg Funston]

Thanks very much Roel. I appreciate it greatly.

Finally on the home stretch. Should be finished in a few days.

Cheers,
Greg Funston SCJP

[Oladeji Oluwasayo]

After so much playing around and watching movies, i've started my URLyBird. I was immediately faced with two problems:
1. The instructions said the DB interface must be implemented exactly as stated which implies that I must create DB.java before its implementation classes. The DB interface in the instrutions used single line comments, should I change them to javadoc or leave them? Because the same instruction said "API documentation should be created for all the classes and interfaces YOU create using the javadoc tool."

2. Can anyone please explain the structure of the content of the data file to me so that i can know the fields i'm working with, 'coz i think someone didn't know how to use punctuation marks when they were creating the instruction so the thing is kind of unclear. Thanks.

[Roel De Nijs]

Hi Oladeji,

1. You can (I didn't).
2. Maybe something went wrong when you saved your instructions, like in this thread. And in the ScjdFaq you can find Roberto's database file reader which will help you understand the database file structure.

Kind regards,
Roel

[Oladeji Oluwasayo]

Hi Roel,

Thanks a lot. I'll download the db reader and continue working.

About the comments and documentation generation, I've already changed them to javadoc and created the documentation but since you left it and still passed, I think I'll reverse it too. I don't want to buy the resubmission exam.

Thanks.

[Oladeji Oluwasayo]

Hey, how do I upgrade to "ranch hand", I don't like this "greenhorn" thing under my name? It makes me

[Oladeji Oluwasayo]

Do you think validating all my input for all the set methods in my HotelRoom class is an overkill? For example, I made a regex validation for the date (yyyy/MM/dd), name (should not exceed 64 characters), customerID (must be all numeric and must be 8 characters) etc, if the requirements are not met, the argument will be truncated to fit in, or padded with blanks, or my default values will be applied and the case may require. An IllegalArgumentException (which is a RuntimeException, so no need for try-catch blocks) is thrown in any case so that the client code will be well informed of whats going on in the database. My code looks like this:

[edit] do not post complete code snippets

Please let me know if this kind of detailed validation is too much for the assignment. I don't want to do beyond what is required. Thanks.

[Roberto Perillo]

Howdy, Oladeji!

Do you think validating all my input for all the set methods in my HotelRoom class is an overkill?

Honestly, yes. There is a way to design software known as design by contract. Basically, it implies that some conditions must be followed before data achieves a particular point. For instance, let's say that we are designing our business layer and defining business methods. We establish a contract: the Room object must not be null when the bookRoom method is invoked. So:

public void bookRoom(HotelRoom room) {
    // We blindly believe that the HotelRoom object isn't null.
    // Therefore, no need to verify room == null, because it certainly isnt' null.
}

The component that invokes this method must not send a null object, and thus, it is his task to verify if everything is correct.

On the other hand, there's the defensive programming, where there is no contract. So, still in the example above:

public void bookRoom(HotelRoom room) {
    // Now we don't believe that the HotelRoom object isn't null
    // Therefore, we verify:
    if (room == null) {...}
}

I myself just generated the getter and setter methods, but if you want, you may justify that you followed a design by contract approach, and therefore, everything will always be ok when the HotelRoom methods are invoked.

[Roberto Perillo]

Oh, and by the way Oladeji, please UseCodeTags when posting code!

[Roel De Nijs]

Oladeji Oluwasayo wrote:Hey, how do I upgrade to "ranch hand", I don't like this "greenhorn" thing under my name?

Have a look at the Saloon Titles.

[Roel De Nijs]

Oladeji Oluwasayo wrote:Please let me know if this kind of detailed validation is too much for the assignment. I don't want to do beyond what is required. Thanks.

In my assignment I use extensive validation, but on different levels. None of these validations happen in my Room-object, because it's justan object which is used to transfer data, so contains no logic at all. Examples of my validations:

in the data class all fields are validated against the database schema

the business service will execute several business validations (like a valid customer id)

my gui validates also the input of the user (if invalid input is provided, the buttons will be disabled)

[Oladeji Oluwasayo]

Roberto Perillo wrote:Howdy, Oladeji!

Honestly, yes. There is a way to design software known as design by contract. Basically, it implies that some conditions must be followed before data achieves a particular point. For instance, let's say that we are designing our business layer and defining business methods. We establish a contract: the Room object must not be null when the bookRoom method is invoked. So:

public void bookRoom(HotelRoom room) {
    // We blindly believe that the HotelRoom object isn't null.
    // Therefore, no need to verify room == null, because it certainly isnt' null.
}

The component that invokes this method must not send a null object, and thus, it is his task to verify if everything is correct.

On the other hand, there's the defensive programming, where there is no contract. So, still in the example above:

public void bookRoom(HotelRoom room) {
    // Now we don't believe that the HotelRoom object isn't null
    // Therefore, we verify:
    if (room == null) {...}
}

I myself just generated the getter and setter methods, but if you want, you may justify that you followed a design by contract approach, and therefore, everything will always be ok when the HotelRoom methods are invoked.

I think I'm also familiar with contract versus secure programming approach to a reasonable extent. The only thing is that I don't know what the markers expect. I had a rethink last night and I also came to think of it that my value object class is too coded around secure programming (some of its methods throw exceptions, runtime exceptions though), makes my test class break when the unsuspecting class tests with non-sense values without a try...catch. The exceptions were intended to notify client code of the modifications made to the parameters before being applied but I have replaced them with log messages. Honestly I also believe that the only integrity I want to maintain is what goes into the database file, I'm the one in charge of what happens in other classes so my HotelRoom does not need all these validation. Rather, the validation codes should go to those classes that will build objects of HotelRoom, and those that will read/write from disk. Thanks a lot ranchers.

[Roberto Perillo]

Oladeji Oluwasayo wrote:The only thing is that I don't know what the markers expect.

They expect you to make decisions based on what is available, so there's no right or wrong. I personally think this is overkill, but if you think it isn't, then go right ahead, because it isn't wrong as well.

[Oladeji Oluwasayo]

I'm through with my LocksKeeper class. Currently working on the Data class then I will implement the façade. Most of my validation intelligence now dwell here. I'm using three Maps, one for recNo--->locationInFile, the second is an implementation of a cache and the third is a cache of deleted records (so that we do not have to hunt through the file to find free space anytime we need to reuse). But I've been thinking lately that adding a boolean field deleted to the value object can eliminate the need for the third Map (since all the objects will now know if their corresponding record has been deleted from the database). Do you think the performance gain and the level of professionalism expected by the markers is worth this refactoring?

[Roel De Nijs]

and what about adding just a null value to the record cache in case of a deleted record? I would object against adding a boolean value to your value object, because when a record is deleted there is simply no value object (because there is no record, it's deleted). When you want to reuse record numbers, just iterate over the map and find the 1st null value.

(just informative: that's exactly the approach I followed in my assignment)

[Roberto Perillo]

Roel De Nijs wrote:and what about adding just a null value to the record cache in case of a deleted record? I would object against adding a boolean value to your value object, because when a record is deleted there is simply no value object (because there is no record, it's deleted). When you want to reuse record numbers, just iterate over the map and find the 1st null value.

Agreed++.

[Oladeji Oluwasayo]

I also thought of using nulls but got stuck. So answer this, if you have multiple null references representing the deleted records in your Map.values(), how do you obtain their respective keys? Because the keys (which are the record numbers) are the stuff we really need.

[Roel De Nijs]

Oladeji Oluwasayo wrote:if you have multiple null references representing the deleted records in your Map.values(), how do you obtain their respective keys?

you have a map with a key (the record number) and a value (the String[] or a value object). The value can be null (representing a deleted record), the key not. So you can easily obtain your keys

[Roberto Perillo]

Here's a possible solution:

Iterator<Long> it = map.keySet().iterator();
while (it.hasNext()) {
    Long recordNumber = it.next();
    Room room = map.get(recordNumber);
    // Here, if the record is deleted, you'll get null; otherwise, the Room object won't be null
}

[Oladeji Oluwasayo]

by saying
public String[] read(int recNo) throws RecordNotFoundException;

Did you guys actually take this recNo as the customerID in your implementation? Because in the database file (in its fresh form), no customerID has been assigned to any record (they're all blanks), meaning that they cannot be used as keys to the cache. I figured out a way around it though, came up with my numbering scheme and preceeding unassigned records with letter E (standing for empty) following that by a seven digit number (just my scheme, anyway). This numbering does not in anyway go into the database, I only used them as keys to my cache. Lemme know if I'm thinking in the right way ranchers.

[Roberto Perillo]

Howdy, Oladeji!

by saying
public String[] read(int recNo) throws RecordNotFoundException;

Did you guys actually take this recNo as the customerID in your implementation?

Oh, no! This is the record number that will be read. This field doesn't exist in the record itself, so this is more of a logical field. Normally, what we do is define the number of appearence of the record in the database file as its number. So, if there are 3 records in your .db file, then the last record will be record number 3.

So, if you want to have a memory cache, you can have something like a Map<Long, Room>, where the key is the record number and the value is the record itself.

[Oladeji Oluwasayo]

All right. Thanks a lot, you just simplified my work