Question

Generally we are using interface concept for RMI implementation also in Event listening ,we are using interfaces .Why cant we use abstract classes in both theses cases.

Answer 1

For events: because the normal situation is that we have an implementation class of our own and it may well neeed to listen to several different events; we can’t extend two different abstract classes.

Skaffman has already explained one issue with using abstract classes for RMI. I’d go a step further, an Abstract Class is just completely the wrong concept for this purpose. The service provider needs to give its clients information about how to call the service. An Interface is exactly what we need for that – it tells the client what can be done and nothing about how it is done. When we give an Abstract class we are including (partial) implementation information. The client has no need to see this, and in an RMI contect may not even be able to compile it – the Abstract Class in the server may refer to classes the client doesn’t even have. Sure you could trim out all the stuff the client does not not need, all the implementation etc, and lo! You’re back with just the information needed in an Interface.

So my practice:

1. Define my Interfaces, my contract with the outside world.

2. If I may have several implementations of that Interface, and especially if I want to help the implementor, define an Abstract Class which implements the Interface. Include the common implementation code in that Abstract Class, and leave some methods abstract for the implementor to actually fill in.

Or to put it simply: Interface for the clients, Abstract Classes for the implementors, and you may well choose to use both. And yes that does imply some duplication, and that’s why we have nice IDEs.