just a small part of the answer - maybe it is not really a practical answer - but still-- 1. For utility purpose - you can extend ONLY ONE abstract class but you can implement any number of Interfaces. 2. Using interfaces you can bring together unrelated entities sharing only that particular feature specified in the interface. But a extending from a class ties you to the Class features in all respects. for more details pls Go to this site for the free download of Java tutorial by Sun Microsystems http://java.sun.com/docs/books/tutorial/information/FAQ.html#bios excuse me if i got your question wrong
Both Interfaces and Abstract classes force anyone that uses them to implement the abstract methods (that is - put real code there). (Yes, you can make an abstract subclass of an abstract class and not implement ALL the methods - but let's skip that). The reason you MAKE an interface is to insure that everything that implements it has a consistant set of behavior (they all have methods that match the interface - and maybe more). This means users of the classes that implement your interface have that warm fuzzy feeling knowing that they can use the familiar methods of your interface, even though they are not very familiar with the class using it. The reason that you might choose to create an abstract class instead of an interface is if you want to provide some methods that already have real code in them (that much less for the next programmer to do) but there are some things that you want to make sure any subclasses can do - but you don't know how to do it for them (it would be so different for each subclass that there is no way to make a common method). The reason you might choose to IMPLEMENT an interface is that you are advertising to the next guy "You can count on me to do all this stuff". You also might want to have all of the variables that might be in the interface at your fingertips. Of course sometimes you Implement an interface cuz you are already sub-classing something else and that is the best that you can do. The reason that you sub-class an abstract class is to take advantage of the code and variables that are already done, as well as guaranteeing the next guy the consistant behavior by implementing the empty methods.
"JavaRanch, where the deer and the Certified play" - David O'Meara
I assume that final methods, variables are allowed in abstract class and not in interface. If that's so then abstract classes make a good choice when there is some basic core functionlaity that I don't want to be changed by sub-classes but being inherited. Similar won't be possible thru interface.
True, interfaces can not have final methods, because all their methods must be empty, and must eventually be implemented somewhere. However they can have variables, and the variables can be final. But yes, you are right, you can protect your methods by making them final - but often you don't want to. Instead you offer default behavior and allow the sub-class to decide if it has any better stuff to do.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com