This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
When you want to have a common signature to your methods (like methods within an interface) and some common behaviors (like methods defined in a super class in an inheritance hierarchy), you can go for an abstract class.
Google is your friend. Some of the best examples are here
Martin Vladimiruk wrote:What are abstract methods and classes for? ... Can anyone give me any example of use?
Yes: AbstractList - In fact all of the 'Abstract...' classes in the Java Collections API.
When is it necessary?
When you have a class (or interface) based hierarchy that you can provide a partial implementation for.
I can not see any necessity to use this.
Maybe not, but some very clever people were involved with creating Java, so you might want to ask yourself why they spent the time to add it. It's also possible that you simply haven't yet encountered a situation where you need it.
Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
I would hazard a guess to say that it is not really necessary to have Abstract methods and classes when you have interfaces, but I know it is extremely convenient and useful to have them.
Winston's example of the AbstractList is a perfect example. The List interface defines all the common method signatures for any list implementation, so AbstractList is not necessary. But since much of what a list does will be the same, regardless of how the list is implemented, you can extract many methods out into a common parent - the AbstractList - so you don't have to have each List implementing class re-implement the same work for what contains() or toString() does (as examples). That means less code, and less code usually means fewer bugs. There are other ways to achieve it, but in this case an abstract parent class makes sense; it is the easiest to implement, easiest to use, doesn't interfere with a clean class-hierarchy.
Finally, since it is abstract it does not have to provide implementations for every method in the List interface; that is good because now you aren't forcing one implementation on child-classes and are forcing child-classes to actually implement the bits that are not common.