I think the problem may be that the implementation of the reserve() method above throws a RemoteExeption - when in the interface IDBAdapter, only ReservationFailedException and InvalidDataFileException are thrown. If in IDBAdapter you define reserve() to throw a RemoteException (or a superclass of RemoteException, for example IOException, which is what I think I will be doing in my similar situation), this would solve the problem.
The reason is that when you implement an interface, you cannot throw new checked exceptions that were not defined in the original interface - unless they are a subclass of one of the originally defined exceptions (I think so anyway!).
[Andrew: added line breaks to the code so that horizontal scrolling is not required] [ June 05, 2005: Message edited by: Andrew Monkhouse ]
Also, in Max's book there's an example which does this interface reuse and it compiles perfectly too.
In Max's book he has the DBClient interface, which, as I understand it, corresponds to your IDBAdapter interface. Each of the methods in the DBClient interface (p173-p174) is declared to throw either an IOException, or an Exception. Note that RemoteException is a subclass of IOException (and obviously Exception). Thus any implementation of DBClient can validly throw a RemoteException for any of it's DBClient methods - since a RemoteException is an IOException.
Your interface IDBAdapter, as I understand it, declares that it's methods throw ReservationFailedException and InvalidDataFileException, which are not superclasses of RemoteException. Therefore any class that implements them cannot throw a RemoteException. As you have seen, an attempt to do so results in a compilation error.
Originally posted by Stan Griffith: So all I am trying to do is figure out a way to reuse my existing interface to make the design clean. How are you dealing with this problem? Do you have two Adapter interfaces for Remote and local connections?
My DBClient class will be as Max's - everything throwing an IOException. I think this is fine, as all the methods relate to accessing a database, so IOException seems perfectly natural.
I'm not sure if you could have a second interface, so have one for remote and one for local connections, and still have a "clean" desgin. For one thing, your GUI/local client should somehow interact with the database, be it local or remote. I think that for the most part it shouldn't really have to worry about what type of connection it is dealing with, and so a single common interface, like DBClient, should be used.
To sum up, I don't think you can reuse your interface without changing it, and keep a clean design.
I hope this helps.
Edit: changed from "I'm not sure if" to "I don't think" in last line. [ June 05, 2005: Message edited by: Michal Charemza ]
I think another reason that it would be difficult to use your existing interface, and a second "remote" interface, is more related to the server side. A class couldn't implement both the remote and local interfaces, due to the fact that one would throw RemoteException in its methods and the other wouldn't. Therefore (I think) the DBAdapter class (as in Max's book) would have to be wrapped in another wrapper that implemented the remote interface.
Come to think of it, for front-end design, a similar thing could be done on the client. i.e. a remote interface object would be received, but then wrapped in a localinterface object for the front-end to interact with, or something similar.
However, this all seems a bit overly complicated, and not clean, to me.