This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Please comment this The public methods of Data class can not be transformed in a remotable interface without modification. In order to be remotable, an impletentation of this interface must declare RemoteException on all methods. When implementing "DataInterface" the compiler will complain if I introduce a new checked exception (RemoteException) that existing clients might not be aware of. My design was based on preserving compatibility with existing clients. Thus, I created RemoteDataInterface with all public methods of the original Data class, declaring RemoteException to each one. I also created RemoteConnection class, implementing RemoteDataInterface, wich is an adapter to the DataInterface. RemoteConnection keeps an instance of the Data class, delegating all method calls to it. If I were not concerned with keeping compatibility with existing code I could make it simpler. Actually, I have not been told to act this way, but, I am assuming that I will be tested on making this kind of judgement, wich is "real life". Is it Overdesign? Do you think I should just create DataInterface with remotable methods and dont bother about this? thanks
Originally posted by Marcos: The public methods of Data class can not be transformed in a remotable interface without modification. In order to be remotable, an impletentation of this interface must declare RemoteException on all methods.
No. While the Remote interface must have a throws RemoteException in all its method signatures, there is no need for its implementations to do so. By which I don't necessarily mean to say that it would be a good idea to turn Data into a Remote class. In fact, based on the information you give here your design is basically fine, but not for the reasons you're suggesting
[...] if I introduce a new checked exception (RemoteException) that existing clients might not be aware of.
What existing clients?
Is it Overdesign? Do you think I should just create DataInterface with remotable methods and dont bother about this?
It's not overdesign, but I'm not sure what DataInterface buys you. At the very least, DataInterface should be a sub-interface of RemoteDataInterface (which should then really be renamed to RemotableDataInterface since implementations are not necessarily remote). One way to approach this is to start with the most generic set-up and apply our trusty little razor to it.Data would implement LocalDataInterface, RemoteConnection would implement RemoteDataInterface (note that its methods would generally not throw RemoteException).An application that needs local database support only would work with LocalDataInterface; an application which should work with either type of implementation (such as FBN) would use DataInterface. Now it's time for the razor. If you know that there will only ever be one local DataInterface implementation, you can dispense with LocalDataInterface. Data would implement DataInterface directly, and an application designed to work with local databases only would simply use Data.Also, if you're not particularly fussed that Data implements Remote, you can dispense with RemoteDataInterface and let DataInterface extend Remote.I'm personally not very fond of this last bit of razor action. Although I couldn't find a formal reason why Data cannot implement Remote, in my opinion an object which is not remoteable at all has no business being instanceof Remote. Others might disagree. In that case you can get things down to one single interface if you wish. - Peter