Question to Authors:Interfaces VS Abstract Classes

Hi,

What should be considered when making a decision on using Java Interfaces vs Abstract Classes? or which should be used where?

Thanks

I realize I'm not the "Authors" you're referring to, but here are some helpful guidelines:

Abstract classes vs. interfaces: When does it make sense to choose an abstract class over an interface?
Abstract classes and interfaces practicum: Move from theory to practice on when to employ abstract classes vs. interfaces
Tech Tips: ABSTRACT CLASSES VS. INTERFACES
Why extends is evil

Why is this a question to the authors???

I do discuss this one in a fair amount of detail in Effective Java Item 16 ("Prefer interfaces to abstract classes"). Here's the summary:

An interface is generally the best way to define a type that permits multiple implementations. An exception to this rule is the case where ease of evolution is deemed more important than flexibility and power. Under these circumstances, you should use an abstract class to define the type, but only if you understand and can accept the limitations. If you export a nontrivial interface, you should strongly consider providing a skeletal implementation to go with it. Finally, you should design all of your public interfaces with the utmost care and test them thoroughly by writing multiple implementations.

Regards,

Josh

Steve,

Thanks for the links, very helpful. Ilja, as those guys have written a book about Java, I guessed they would have the exact correct answer for me, maybe there is something in their book that they have written regarding this, especially as their book seems to be gearded towards experienced coders.

I am not an author, but I'll try.

If you want to generalize the behavior of a bunch of classes, then you create an interface and make the classes implement that interface. A good example is the Java Collections Framework, where for example, the List interface defines the behavior of any implementation of a List data structure (like ArrayList, Vector, etc.)

If you want to generalize the structure (and may be a little bit of behavior) of a bunch of classes, then you create an abstract class. A good example is the JComponent class in Swing, which is the common class to most of the widgets in Swing.

Originally posted by M Jay:
Steve,

Thanks for the links, very helpful. Ilja, as those guys have written a book about Java, I guessed they would have the exact correct answer for me, maybe there is something in their book that they have written regarding this, especially as their book seems to be gearded towards experienced coders.

Interfaces and Abstract classes are really Object-Oriented Programming concepts and not really specific to Java. By directing a question to a specific set of people (not that Joshua can't answer it - he has written some of the best books in Java), you are losing the perspectives of different people from different backgrounds and areas of expertise, which normally comes in handy.

Originally posted by Sathya Srinivasan:

Interfaces and Abstract classes are really Object-Oriented Programming concepts and not really specific to Java.

In my view, interfaces are specific to languages without multiple inheritance. In languages with multiple inheritance, interfaces are equivalent to fully abstract classes.

Or, with other words, the only difference between an interface and a fully abstract class in java is that the interface allows for multiple inheritance.

Originally posted by Sathya Srinivasan:
I am not an author, but I'll try.

If you want to generalize the behavior of a bunch of classes, then you create an interface and make the classes implement that interface. A good example is the Java Collections Framework, where for example, the List interface defines the behavior of any implementation of a List data structure (like ArrayList, Vector, etc.)

If you want to generalize the structure (and may be a little bit of behavior) of a bunch of classes, then you create an abstract class. A good example is the JComponent class in Swing, which is the common class to most of the widgets in Swing.

This is very good explanation with nice example.

hello,

Originally posted by Sathya Srinivasan:

If you want to generalize the behavior of a bunch of classes, then you create an interface and make the classes implement that interface. A good example is the Java Collections Framework, where for example, the List interface defines the behavior of any implementation of a List data structure (like ArrayList, Vector, etc.)

If you want to generalize the structure (and may be a little bit of behavior) of a bunch of classes, then you create an abstract class. A good example is the JComponent class in Swing, which is the common class to most of the widgets in Swing.

I disagree with that, and the swing API is not designed very well. If there are common features that many implementing classes of an interface would need, then make an abstract class that implements your interface. An example for this design is java.util.List and java.util.AbstractList. With this approach clients of your API can still make their own interfaces which extend your interface. If you would only provide an abstract class that would not be possible. This is only one of many reasons why the strict "abstract class" approach is wrong.

Using an abstract class as a type (declaration, parameter or return type) violates the principle of programming to an interface.

I wrote something about that here. We also had the same discussion a couple of weeks ago in this thread.

Kai