Alex Duran

Greenhorn
+ Follow
since Jan 29, 2007
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Alex Duran

I'm currently attempting to complete the programming assignment for URLyBird 1.1.2 and I am grappling with what is probably the most basic design question:

When the application is operating in true client-server mode (i.e. client-side GUI in one JVM makes RMI calls on a remote object in a separate JVM - aka the Server) - is it OK to implement a design where "lock" and "unlock" methods ARE NOT invoked by the client-side GUI.

In other words, I'm favoring a design where the remote interface does not resemble the suncertify.db.DB interface with RemoteException added to the method signatures. Rather, this remote interface would look like a business object (methods would have names like "bookReservation", "queryAllReservations", "queryReservationByHotelName", etc.).

I believe this design is also called "Thin-Client". Although this design requires changes in two abstraction layers (business object and client) when another business operation (such as deleting a reservation) is added later, I think I can justify the design because it insulates the client-side GUI from the data access implementation.

Has anybody passed URLyBird 1.1.2 using server-side locking/thin-client design without losing a lot of points in the locking section?

By the way, in URLyBird 1.1.2 the lock and unlock signatures look like:




I tried to get an answer from this thread before posting this question:

https://coderanch.com/t/184224/java-developer-SCJD/certification/Should-lock-methods-callable-client

But I just couldn't find an answer in the 140 posts. I tried, really I did!

[ February 05, 2007: Message edited by: Alex Duran ]

[ February 05, 2007: Message edited by: Alex Duran ]

[ February 05, 2007: Message edited by: Alex Duran ]

[ February 05, 2007: Message edited by: Alex Duran ]

[ February 05, 2007: Message edited by: Alex Duran ]
[ February 05, 2007: Message edited by: Alex Duran ]
I missed a '{' after 'doWhenCondition()' above.


(No - you didn't -- use the paper/pencil icon to edit your posts.)
[ February 02, 2007: Message edited by: Barry Gaunt ]
There are many posts in the forum concerning the locking design. I think this one is particularly useful: https://coderanch.com/t/187926/java-developer-SCJD/certification/Locking-Approach

It help me to think of the wait/notifyAll mechanism as a means by which threads communicate with one another.

Basically, as I see it, threads often encounter similar conditions where its work cannot proceed without a change in the state of some object or other. The notifyAll method is sort of like a thread making a general announcement to all threads that it's changed the state of an object such that the condition on which one or more threads has been waiting - may now be satisfied.

Looking at the "Threads" Chapter in "The Java Programming Language, Third Edition", the authors characterize the pattern as:


[ February 02, 2007: Message edited by: Barry Gaunt ]
I have a question regarging where I ought to be doing data validation. I'm not concerned about the mechanics of how to do this - I think that the java.text and java.util.regex packages will have all of what I need for the checking operations themselves.

I'm more concerned about where the checks should be performed. I have a couple thoughts:

A) The database schema in the form of field lengths and formats (e.g. yyyy/mm/dd for the date the room is available) is available from the database file. In my opinion, checking of the field lengths and formats needs to be done in the database layer (the suncertify.db.Data class, a subclass or delegates of same) because this checking is essential to ensure the data can be properly stored. I'm pretty sure that this is the way to do it.

B) The 48 hour threshold for reserving a room is a buisnes rule. It is independent of the data storage mechanism and, as a result, this sort of check should not be in the database layer. My first guess is that I could create a subclass of AbstractTableModel and registered listeners could call some sort of business object to perform this type of valdiation - when the appropriate event is fired. Does that seem correct or can people suggest a better way?

C) I can't help but think that some form of field format and length validation should be performed before an attempt is made to update the database. Do people have ideas on what is appropriate here?

The implementation of C seems the most difficult. The Data class can easily query the database file at startup for its schema. But if I'm going to validate field format and length, there needs to be some way of publishing this information where it can be used outside the database layer. I would expect this needs to account for the possibility that the order of data fields could change, the names of the fields could change, field lengths and formats could change, etc.

Any thoughts here, too?

ThanksQ!
Rudolph,

Thank you for your reply.

The intent behind using Template Method is that if, for some reason the format of the data file were to change or the database were to change to something that did not use a file at all, those changes would be encapsulated elsewhere. The checks for pre-conditions, post-conditions, etc. could remain in the suncertify.db.Data class, however, since these will not change unless the interface of suncertify.db.DB changes.

What do you think? Maybe I have lost my mind
One correction...the line in the 2nd code example that reads:



Should have read:

I'm currently working on URLyBird (1.1.2) and the instructions contain the following statement:

Your data access class must be called "Data.java", must be in a package called "suncertify.db", and must implement the following interface:

[Definition of sunceritfy.db.DB interface follows...]

My question is - what is the scope of a "data access class"?

Minimally, it's clear that the class declaration for suncertify.db.Data must look like:



But does "Data Access Class" also mean that all aspects of the data access - including locking, file access, etc. must also be contained within the suncertify.db.Data class?

For example, let's say I wanted implement the "create" method in Data.java as follows:



where "doCreate" would be defined as an abstract method (thereby making suncertify.db.Data an abstract class) that would be overridden by subclasses that provide an implementation (e.g. a FixedFieldDataFile subclass would provide an implementation required for this assignment). In other words, I'd use a Template Method pattern.

Would the above approach (and similar) where implementation details have become the responsibility of classes other than suncertify.db.Data violate the requirement that mandates that suncertify.db.Data serve as the "Data Access Class"?

Thank you.
I'm finally resuming work on my SCJD assignment (I purchased the assignment in 2002...better late than never).

I have two questions regarding the creation of JavaDoc for the assignment. The instructions read:

"Awkward or complex code should have descriptive comments, and javadoc style comments must be used for each element of the public interface of each class. You must create a full suite of documentation for the classes of the completed project. This must be generated using the tool "javadoc" and must be in HTML format. Provide javadoc documentation for all classes you write."

My questions are:
a) Has anybody elected to generate JavaDoc comments for "protected" members as well? In the real world, I would be inclined to always document "protected" members since they are contractual (i.e. this is available to subclasses outside the package or the class itself). And if you did generate these comments - were points deducted for doing so?

b) Did you also create JavaDoc comments for the supplied suncertify.db.DB interface? The source code has been provided for this interface, but it does not include documentation comments. I would like to create JavaDoc comments for this interface (and maybe add some whitespace characters!), but I am concerned that the graders my automatically fail any assignment that introduces any changes to DB.java.

Thank you.