This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Abstract classes gives the extending subclasses a default list of functionality. If you think it will increase this default list of functionalities in the future, then you can use abstract classes. Because if that's an interface and you go and add an additional method to be supported by a class, then you break all the classes that implement that interface.
On the other hand interfaces saves a particular class from joining a hierarchy simply to achieve some behavior. You can make a class extend (if needs) from a more suitable is-a super class and mark the class to implement interfaces to achieve other desired behaviors.
I hope searching in the forum will lead you to better results.
I ran into a very good explanation of this question some time back and I have been searching for it ever since [ bookmarking it would have been the way to go ].
@John, I have seen somewhere that if two classes are not closely related yet have some behavior in common, then usually the developer needs to go with Interfaces and if the relationship between them is strong, then the developer needs to go with Abstract classes. You seem to stress on something similar. Could you please explain it further .