This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
- need to have some concrete method implementations within the superclass itself, and a few abstract methods which would be implemented by the concrete subclasses.
- are absolutely sure that the abstract class' subclasses will not need to extend any other class. Remember, Java allows you to extend only one class.
When you use an interface, you:
- cannot provide an implementation for any method you create. In other words, all the methods that are defined are implicitly abstract.
- can implement the interface in another class and also, extend another class and implement many more interfaces as needed.
Bottomline - Interfaces allow you to implement as many interfaces as you want, and you are also allowed to extend one class. But the trade off is that you must implement ALL of the interface's methods in the first concrete (non-abstract) implementing class.
I just want to add that in real world situations, I found that the Interfaces are usually created by the lead developer or designer of the software development. Then the rest of the development team are tasked to created whatever abstract classes and concrete classes by using those Interfaces.
In other words, based on what Anurag said, the senior developers decide on and design the Interfaces to mandate all the required functionalities (i.e., the methods) without having to write all the necessary code. Then that is followed by further development of abstract and concrete classes. Therefore in a collaborative work environment, it's the process that decides most of the choices between Interface and abstract class.