There are three differences between an interface and an abstract class:
- you can implement multiple interfaces at the same time, but only extend one class,
- an abstract class is allowed to contain implementation (non-abstract methods, constructors, instance initializers and instance variables) and non-public members, and
- abstract classes may be a tiny bit faster (or they may not.)
Actually the first point is the reason for the existence of interfaces in Java: to provide a form of multiple inheritance. In languages with multiple implementation inheritance, an interface would be equivalent to a fully abstract class (a class with only public abstract members).
The above differentiation suggests when to use an abstract class and when to use an interface:
- use an abstract class, if you want to provide common implementation to subclasses,
- use an abstract class, if you want to declare non-public members,
- use an abstract class, if you want to be free to add new public methods in the future,
- use an interface if you're sure the API is stable for the long run
- use an interface if you want to provide the implementing classes the opportunity to inherit from other sources at the same time.
In general, prefer interfaces if you don't need to use an abstract class, because they provide more design flexibility.
11/29/07 Stan James: Added two bullets about the ability to add methods to an abstract class without breaking any clients. If you add a method to an interface, you break all implementations. This puts a different spin on "flexibility" in the paragraph above. This distinction did not occur to me on my own; I just ran across it in Kent Becks Implementation Patterns.
See InterfaceVsAbstractClassDiscussion
Other resources:
