aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes DataInterface: Methode close Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "DataInterface: Methode close" Watch "DataInterface: Methode close" New topic
Author

DataInterface: Methode close

pascal auderset
Greenhorn

Joined: Aug 21, 2002
Posts: 15
Hi
In the Submission Sun states the the client has to include a class with the same public methods as the suncertify.db.Data class.
My question is now: How do you handle the close Methode in the remote case?
In my design I use only one Instance of the class Data in the server environment. So if one client calls the close method the db will be closed and other clients can't access anymore.
Thanks
Pascal
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

So if one client calls the close method the db will be closed and other clients can't access anymore.

This is obviously not acceptable in remote mode.
You have several choices here:
-- leave the close() method empty for remote object
-- throw a "method not supported" exception when the close() method is called remotely

Eugene.
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by Eugene Kononov:
You have several choices here:
-- leave the close() method empty for remote object
-- throw a "method not supported" exception when the close() method is called remotely
Are you just listing the options without worrying about their merit for now, or do you mean to say that the second choice is a defensible design choice? Because I would contend that it isn't.
The second choice would require the client to be aware whether the DataInterface implementation it was using was local or remote. This would point to a flawed understanding of the interface concept. Interface implementations should satisfy the substitution rule for inheritance: wherever you are using an interface, you should be able to use any implementation of that interface in exactly the same way. The Java compiler takes care of ensuring that this rule is satisfied at the language level, but it is often not appreciated that you as a developer must take care of ensuring that this rule is satisfied at the semantical level.
Read this thread for a discussion of the close() method in particular.
- Peter
[ January 15, 2003: Message edited by: Peter den Haan ]
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

Peter wrote:
The second choice would require the client to be aware whether the DataInterface implementation it was using was local or remote. This would point to a flawed understanding of the interface concept. Interface implementations should satisfy the substitution rule for inheritance: wherever you are using an interface, you should be able to use any implementation of that interface in exactly the same way.

I absolutely agree. However, my point is that throwing a "method not supported" is as legitimate implementation as an empty method, or a method that actually does some work. For example, here is a javadoc for the getNameInNamespace() method in Sun's Context class:
"In naming systems for which the notion of full name does not make sense, OperationNotSupportedException is thrown."
By analogy, it doesn't make sense for a remote client to close the database on the server, hence the justification for throwing an exception.
Perhaps a method like this should not be in the interface in the first place (since it forces the implementing classes to provide a "fake" implementation), but that's a separate issue.
Eugene.
[ January 15, 2003: Message edited by: Eugene Kononov ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: DataInterface: Methode close