Where to use abstract class and Interface?

[Mihir Patel]

Please let me know in which situation we should use abstract class and where to use Interface?

[Stephan van Hulst]

In general, prefer interface. Their use is more flexible; users can easily make their classes implement multiple interfaces.

Abstract classes have the advantage that they can supply default implementations, and they can easily add new methods without breaking subtypes.

When you find yourself creating an abstract class, you should also provide an interface it implements. This gives your clients the choice whether they want to use the interface or the abstract class. When you design an interface, make sure you plan it out well. Once an interface is released, it's impossible to change.

Two counter-examples from the standard API: the Observable and InputStream classes should have been interfaces instead of classes. In my opinion this was a huge oversight.

[Luigi Plinge]

You might like to read Bill Venners' article on inheritance vs composition (with interfaces).

[Pat Farrell]

I often use both. I define the interface, and then provide an abstract base class that implements common functions, leaving the specialization to the subclasses that "implement" the interface and inherit/extend the abstract base.

[Seetharaman Venkatasamy]

Pat Farrell wrote:I often use both. I define the interface, and then provide an abstract base class that implements common functions, leaving the specialization to the subclasses that "implement" the interface and inherit/extend the abstract base.

this is what exactly effective java recommended , and named as skeletal implementation of an interface . often called Abstract Interface.

[Rob Spoor]

Stephan van Hulst wrote:Abstract classes have the advantage that they can supply default implementations, and they can easily add new methods without breaking subtypes.

This approach is used within the collections framework; interfaces Collection, List, Set and Map with skeleton implementations AbstractCollection, AbstractList, AbstractSet and AbstractMap.

Two counter-examples from the standard API: the Observable and InputStream classes should have been interfaces instead of classes. In my opinion this was a huge oversight.

+5. Those two have been on my "rant list" for ages. I even wrote my own copies of Observable / Observer, this time with generics built in, and with Observable being an interface with abstract implementation class, and even an ObservableHelper that

can be used in classes that need to implements Observable but already extend a different class.

(direct quote from my Javadoc including the little grammar mistake I saw just now...)

[Stephan van Hulst]

Rob Spoor wrote:This approach is used within the collections framework; interfaces Collection, List, Set and Map with skeleton implementations AbstractCollection, AbstractList, AbstractSet and AbstractMap.

The collection framework is a dream to work with. This is a truly well designed API.

I even wrote my own copies of Observable / Observer, this time with generics built in, and with Observable being an interface with abstract implementation class, and even an ObservableHelper that

can be used in classes that need to implements Observable but already extend a different class.

Awesome. I'm very curious about the generics part. Do you have a link to your Javadoc?