Originally posted by Stan Griffith:
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.
Michal.
Edit: changed from "I'm not sure if" to "I don't think" in last line.
[ June 05, 2005: Message edited by: Michal Charemza ]