This week's book giveaways are in the Refactoring and Agile forums.
We're giving away four copies each of Re-engineering Legacy Software and Docker in Action and have the authors on-line!
See this thread and this one for details.
Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

DataInterface: Methode close

 
pascal auderset
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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 ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic