my dog learned polymorphism*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Polymorphism and Automatic Failure 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 "Polymorphism and Automatic Failure" Watch "Polymorphism and Automatic Failure" New topic
Author

Polymorphism and Automatic Failure

Simon Ingram
Ranch Hand

Joined: Nov 30, 2003
Posts: 173
Hello there, my fellow ranchers!
Most of the projects define an interface that we have to implement. In my case this is called DB. Anyone using rmi will have to define a second interface that extends Remote and throws RemoteException on all methods. Let's call it DBRemote. It would be useful to define an interface supertype to define a connection, let's call it Con. Then since local connection (DB) and network connection (DBRemote) are subtypes of Con, a reference variable con can be used to handle any type of database connection.
So, I have a Sun supplied DB interface DB as follows:
public interface DB {
can I change it to:
public interface DB extends Con {
without getting an Automatica failure for not implementing the DB interface as supplied?
With best regards,
Simon Ingram
Charlie Goth
Ranch Hand

Joined: Feb 26, 2004
Posts: 60
Lots of people seem to think that the interface provided (DB in your case) should be used by the client to connect to the database in local mode, I don't believe this to be the case.
I've created an abstract connection, an rmi connection and a local connection, with an initialised DB in both the local connection and the rmi connection impl classes. Depending on your design, you may not want the client to explicitly lock and unlock records etc, so why expose more than is necessary.
ps - I think it's a safe bet that NO you don't want to change the code they provide.
Charlie


SCJP (77%)
Satish Avadhanam
Ranch Hand

Joined: Aug 12, 2003
Posts: 697
Hi Simon, I agree with Charlie. Its not safe to change the given db file or interface.
Here are my 2 cents. The idea of yours is perfect i.e. to give the same reference to client for both local and remote operations. You can achieve the same thing as follows:

Now you can send the same reference X for both local and remote clients. Note that X does not extend DB, but you can try your Data class implementing both DB and X.
Good Luck
Simon Ingram
Ranch Hand

Joined: Nov 30, 2003
Posts: 173
Thanks guys. The information was very helpful. When the instructions say that our data access class MUST be called Data and MUST implment DB, I assumed that we could not start creating new interfaces using only some of the methods and simply ignore DB and Data!
Also there are the method signatures to consider. If interface X contains, for example


and interface Y extends X, any class that implements Y will have to provide method bodies for

this seems a little untidy to me. Is it possible to change the method signature in X to include the RemoteException? Before reading your posts I thought I was stuck with the method signatures provided by Sun.
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
Hi Simon,
What if your X interface only declared read to throw IOException? Then any class that implements Y would only have to provide method bodies for:

since RemoteException is a subclass of IOException.
Of course, then you're left with the problem of how to go from a Sun-provided interface that declares read as follows:

to the X interface that declares read as follows:

The object adapter design pattern is one way to adapt the X interface to the Data class (which implements the Sun-supplied interface). If you do this you'll end up wrapping the RecordNotFoundExceptions in an IOException. This bothers some people, but seemed reasonable to me.
Anyway, this is just one way to go. There are others. There's no perfect way to go from the Sun-supplied interface to one that can serve as a common interface for both local and remote database access.


Regards, George
SCJP, SCJD, SCWCD, SCBCD
Satish Avadhanam
Ranch Hand

Joined: Aug 12, 2003
Posts: 697
Hi Simon, here's an alternative.

The reason why X should methods should throw IOException is like this. Say suppose you are providing only two business specific methods for client in X, then in as you know all operations on db file are IO based, they throw IOException(like RAF.read() for example). So you let methods of X implement IOException. As RemoteException is a subclass of RemoteException, you don't need to implement two methods, only one will suffice.
If you are still not convinced, then here is an alternative answer -- You document in the following way, To make my remote class implement only one method and to make code understandable and clear, I have made X implement IOException. This should work
Good Luck.
Satish Avadhanam
Ranch Hand

Joined: Aug 12, 2003
Posts: 697
Well, by the time I answered, George already explained it. Thanks George.
Simon Ingram
Ranch Hand

Joined: Nov 30, 2003
Posts: 173
Thanks guys for your lucid explanations. I will see what I can find out about the object adapter pattern, but neither of you guys seem to think it necessary! My reading of the SCJD instructions suggest that we are stuck with the method signatures provided, but you say just make an interface with methods that throw IOException! Marvellous. This is how it is in the real world, after all. But the exam is an artificial world, so to me, it seems that we can't simply not use the Sun interface provided. Clearly I am wrong, because you guys have already passed the exam, right? SO thanks very much, I shall now throw caution to the wind!
all the best
Simon
Satish Avadhanam
Ranch Hand

Joined: Aug 12, 2003
Posts: 697
Originally posted by Simon Ingram:
because you guys have already passed the exam, right?
all the best
Simon

Am still doing...but George did
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
Hi Simon,
Originally posted by Simon Ingram:
...I shall now throw caution to the wind!

Whoa! Don't throw all your caution to the wind. You still need a Data class and it still needs to implement the Sun-supplied interface. What Satish and I are talking about is the fact that the Sun-supplied interface is not very useful for creating another interface that supports remote database access. You are free to create your own interface. In fact this interface might look identical to the Sun-supplied one, except that it might have methods that throw IOException rather than RecordNotFoundException. In other words, this new interface you create might be very useful for creating another interface that supports remote database access.
So you have a situation where you've written your Data class to implement the Sun-supplied interface (as your required to do by the assignment instructions). But you don't really want to use the Sun-supplied interface because you can't extend it easily to create an interface that supports remote database access. You really want to use your new (nearly identical to the Sun-supplied interface but throwing a type of exception that will make it easier for you to create your remote interface) interface to access the database methods in the Data class. The object adapter design pattern can ride to the rescue by adapting your new interface to the Data class (which implements the old Sun-supplied interface).
Some people take this an extra step (I believe Satish is one) and say that as long as I'm creating a new new interface why do I need to make it look like the Sun-supplied one. Why don't I put in only the methods in this new interface that I intend to call in the GUI client? Other people (myself included) decide to make the new interface look nearly identical to the old Sun-interface. Both approaches can lead to successful implementations.
So neither Satish nor I are throwing the Sun-supplied interface away. It's the interface that the Data class implements. But for the reasons discussed before we do not wish our clients to use the Sun-supplied interface to call any of the database methods. Instead we have our clients call the database methods in the new database access interface. When one of our clients calls a method in the new database access interface that method is delegated by the adapter class to the Data class for execution.
Satish Avadhanam
Ranch Hand

Joined: Aug 12, 2003
Posts: 697
Hey George, its your 500th post. 500 very valuable, lengthy, descriptive, informative, doubt-clarifying(Well, I think I should stop, else it goes on & on.... see ) posts to many ranchers...

Man...you Rock!!
Originally posted by George Marinkovich:
Hi Simon,
Some people take this an extra step (I believe Satish is one) and say that as long as I'm creating a new new interface why do I need to make it look like the Sun-supplied one. Why don't I put in only the methods in this new interface that I intend to call in the GUI client? Other people (myself included) decide to make the new interface look nearly identical to the old Sun-interface. Both approaches can lead to successful implementations.

That's right George. I only have two methods in the interface.
[qb][/QB]
Maria Lepschy
Ranch Hand

Joined: Jan 12, 2004
Posts: 78
Hi George, Satish,
It is Ok if the RecordNotFoundException and SecurityException extends IOException?
Thanks,
Maria
Satish Avadhanam
Ranch Hand

Joined: Aug 12, 2003
Posts: 697
Originally posted by Maria Lepschy:
Hi George, Satish,
It is Ok if the RecordNotFoundException and SecurityException extends IOException?
Thanks,
Maria

Hi Maria, SecurityException is a pre-defined RuntimeException in API. I think we are supposed to throw that exception instead of defining our own exception class and extending it. However, for RecordNotFoundException we have to define it extending another Exception class. Here is link where exceptions are this issue discussed...
Exceptions thrown from interface provided by Sun?
If you still have any doubts, you can post the questions in that thread as it will be easy to read and answer for others.
Thanks.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Polymorphism and Automatic Failure