interface vs abstract class
When should you use an
abstract class, when an
interface, when both? Interfaces and
abstract classes seemsuperficially to provide almost the same capability. How do you decide which to use?
When To Use Interfaces | Interface Details |
When To Use Abstract classes | Abstract Details |
When To Use Both | Links |
Summary Table |
When To Use Interfaces
An interface allows somebody to start from scratch to implement your interface or implement your interface in some other code whoseoriginal or primary purpose was quite different from your interface. To them, your interface is only incidental, something that have to add on to the their code to beable to use your package. The disadvantage is every method in the interface must be public. You might not want toexpose everything.When To Use Abstract classes
An abstract class, in contrast, provides more structure. It usually defines somedefault implementations and provides some tools useful for a full implementation. The catch is, code using it must use your class as the base. That may be highly inconvenient if the other programmers wanting to useyour package have already developed their own class hierarchy independently. In Java, a class can inherit fromonly one base class.When to Use Both
You can offer the best of both worlds, an interface and an abstract class. Implementors can ignore your abstract class if theychoose. The only drawback of doing that is calling methods via their interface nameis slightly slower than calling them via their abstract class name.Summary Table
Interfaces vs Abstract Classes | ||
---|---|---|
feature | interface | abstract class |
multiple inheritance | A class may implement several interfaces. | A class may extend only one abstract class. |
default implementation | An interface cannot provide any code at all, much less default code. | An abstract class can provide complete code, default code, and/or juststubs that have to be overridden. |
constants | Static final constants only, can use them without qualification in classes that implement theinterface. On the other paw, these unqualified names pollute the namespace.You can use them and it is not obvious where they are coming from since the qualification is optional. | Both instance and static constants are possible. Both static and instance intialiser code are alsopossible to compute the constants. |
third party convenience | An interface implementation may be added to any existing third partyclass. | A third party class must be rewritten to extend only from the abstractclass. |
is-a vs -able or can-do | Interfaces are often used to describe the peripheral abilities of a class, not its central identity,e.g. An Automobile class might implement the Recyclable interface, which could apply to many otherwisetotally unrelated objects. | An abstract class defines the core identity of its descendants. If youdefined a Dog abstract class then Dalmatian descendants are Dogs,they are not merely dogable. Implemented interfaces enumerate the general things a class can do, not thethings a class is. In a Java context, users should typically implement the Runnable interface rather than extending Thread, because they’renot really interested in providing some new Thread functionality, theynormally just want some code to have the capability of running independently. They want to createsomething that can be run in a thread, not a new kind of thread.The similar is-a vs has-a debate comes upwhen you decide to inherit or delegate.
multiple inheritance for further discussion of is-a vs has-a
|
plug-in | You can write a new replacement module for an interface that contains notone stick of code in common with the existing implementations. When you implement the interface, you startfrom scratch without any default implementation. You have to obtain your tools from other classes; nothingcomes with the interface other than a few constants. This gives you freedom toimplement a radically different internal design. | You must use the abstract class as-is for the code base, with all itsattendant baggage, good or bad. The abstract class author has imposedstructure on you. Depending on the cleverness of the author of the abstractclass, this may be good or bad. |
homogeneity | If all the various implementations share is the method signatures, then an interface works best. | If the various implementations are all of a kind and share a common status and behaviour, usually anabstract class works best. Another issue that’s important is what I callheterogeneous vs. homogeneous. If implementors/subclasses are homogeneous, tend towards anabstract base class. If they are heterogeneous, use an interface. (Now all I have to do is come up with a good definition of hetero/homo-geneousin this context.) If the various objects are all of-a-kind, and share a common state and behavior, thentend towards a common base class. If all they share is a set of method signatures, then tend towards aninterface. |
maintenance | If your client code talks only in terms of an interface, you can easilychange the concrete implementation behind it, using a factory method. | Just like an interface, if your client code talks only in terms of anabstract class, you can easily change the concrete implementation behind it,using a factory method. |
speed | Slow, requires extra indirection to find the corresponding method in the actual class. Modern JVMs (Java Virtual Machines)arediscovering ways to reduce this speed penalty. | Fast |
terseness | The constant declarations in an interface are all presumed public static final, so you may leave that part out. You can’t call any methods tocompute the initial values of your constants. You need not declare individual methods of an interface abstract. They are all presumed so. | You can put shared code into an abstract class, where you cannot into aninterface. If interfaces want to share code, you will have to write otherbubblegum to arrange that. You may use methods to compute the initial values of your constants andvariables, both instance and static. You must declare all the individual methods of an abstract class abstract. |
adding functionality | If you add a new method to an interface, you must track down allimplementations of that interface in the universe and provide them with aconcrete implementation of that method. | If you add a new method to an abstract class, you have the option ofproviding a default implementation of it. Then all existing code will continue to work without change. |