aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Clarification of the requirements Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Clarification of the requirements" Watch "Clarification of the requirements" New topic
Author

Clarification of the requirements

Cathy Young
Ranch Hand

Joined: Mar 02, 2002
Posts: 126
Hi,
In more than one place of the instruction document, it says the data client "should include a class that implements the same public methods as the suncertify.db.Data class". I am wondering what it means by "implementing the same methods as Data clas"? Should we implement a set of methods as in Data class? Why can't we use it? Am I misunderstanding it at all?
Can someone help?
Thanks,
Cathy
Nate Johnson
Ranch Hand

Joined: May 13, 2002
Posts: 301
I took this to mean we should have an interface that has the same methods as the Data class... then use this interface to create local and remote implementations that would talk to the Data object. If you go with an RMI approach, you will need an interface anyway, because you can not serialize the Data object since it has a RandomAccessFile in it.
Chosing to break it up like this helps separate out the functionality of the two... for example, locking and unlocking can be done in the remote implementation. This is one of the reasons that I chose to extend the database, which was your other question that you posted.
Hope this helps,


scwcd, scjd, scjp<br /><a href="http://natejohnson.us" target="_blank" rel="nofollow">http://natejohnson.us</a><br /><a href="http://rice.kuali.org" target="_blank" rel="nofollow">http://rice.kuali.org</a>
Cathy Young
Ranch Hand

Joined: Mar 02, 2002
Posts: 126
Originally posted by Nate Johnson:
I took this to mean we should have an interface that has the same methods as the Data class... then use this interface to create local and remote implementations that would talk to the Data object. If you go with an RMI approach, you will need an interface anyway, because you can not serialize the Data object since it has a RandomAccessFile in it.
Chosing to break it up like this helps separate out the functionality of the two... for example, locking and unlocking can be done in the remote implementation. This is one of the reasons that I chose to extend the database, which was your other question that you posted.
Hope this helps,

Hi, Nate,
Thank you for your reply, and it does make sense to me. But I am still kind of confused: in my understanding, the difference between the local and remote modes is which database file is used, and the difference between the implementation is whether to bypass the network connection (and thus lock and unlock). So I am thinking the way to access the database file (after locating it) is the same for local and remote mode except for locking. Is it right or am I missing something?
Thanks,
Cathy
Nate Johnson
Ranch Hand

Joined: May 13, 2002
Posts: 301
Yeah, I accessed my local data by extending the Data class and implementing my interface. For the remote mode, I just kept a reference to the Data and called the public methods on it with the same methods in the remote class as well as implementing the common interface.
By having these two classes, it helps separate your code into logical pieces that are easier to work with for future maintainers.
Also, by using the common interface, your client code does not need to be concerned with which mode it is in, it just always talks to your interface.
Did that help at all? I was not too sure of your question
Cathy Young
Ranch Hand

Joined: Mar 02, 2002
Posts: 126
Originally posted by Nate Johnson:
Yeah, I accessed my local data by extending the Data class and implementing my interface. For the remote mode, I just kept a reference to the Data and called the public methods on it with the same methods in the remote class as well as implementing the common interface.
By having these two classes, it helps separate your code into logical pieces that are easier to work with for future maintainers.
I understand this now. Thanks!

Also, by using the common interface, your client code does not need to be concerned with which mode it is in, it just always talks to your interface.
If the client is not concerned with which mode it is in, who will be concerned with it? What I am thinking of doing is to differentiate the mode by the command line args. If the server name is specified while client starts, it is in remote mode, otherwise, it is in local mode. Does this sound reasonable for you?

Did that help at all? I was not too sure of your question [/QB]
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
Hi Cathy,

What I am thinking of doing is to differentiate the mode by the command line args. If the server name is specified while client starts, it is in remote mode, otherwise, it is in local mode. Does this sound reasonable for you?

That's a very good approach Cathy. I think that is exactly what Mark did. I did something similar but had some optional parameters, namely the RMI port which had to be preceded by "-p" for remote mode and an optional db file path preceded by "-f" for local mode.
Hope this helps,
Michael Morris
[ August 18, 2002: Message edited by: Michael Morris ]

Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
Nate Johnson
Ranch Hand

Joined: May 13, 2002
Posts: 301
I just meant from a coding perspective, you can just deal with the interface and not need an if check every time you are talking to the local or remote data object.
I used the command line to distinguish between modes at startup too
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Clarification of the requirements