Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Clarification of the requirements

 
Cathy Young
Ranch Hand
Posts: 126
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 301
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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,
 
Cathy Young
Ranch Hand
Posts: 126
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 301
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 126
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Nate Johnson
Ranch Hand
Posts: 301
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic