Interfaces VS Abstract Classes ...
A Side by Side Comparison Of Features of Interfaces and Abstract Classes.
By: Naveen Date: October 23, 2003
Printer Friendly Version
Interface vs Abstract Class
.
Interfaces vs Abstract ClassesFeatureInterfaceAbstract classMultiple inheritanceA class may implement several interfaces.A class may extend only one abstract class.Default implementationAn interface can not provide any code at all, much less default code.An abstract class can provide complete code, default code, and / or just stubs that have to be overridden.ConstantsStatic final constants only, can use them without qualification in classes that implement the interface. 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 also possible to compute the constants.Third party convenienceAn interface implementation may be added to any existing third party class.A third party class must be ReWritten to Extend Only from the Abstract Class.is-a vs Able or Can-Dointerfaces Are Offen Used to de DE scribe the peripheral abilities of a class, not its central identity, eg an Automobile class might implement the Recyclable interface, which could apply to many otherwise totally unrelated objects.An abstract class defines the core identity of its descendants. If you defined a Dog abstract class then Damamation descendants are Dogs, they are not merely dogable. Implemented interfaces enumerate the general things a class can do, not the things a class is.Plug-inYou can write a new replacement module for an interface that contains not one stick of code IN Common with the existing iMplementations. You Start from scratch without any default us. You have to obtain your tools from other classes
nothing comes with the interface other than a few constants. This gives you freedom to implement a radically different internal design.You must use the abstract class as-is for the code base, with all its attendant baggage, good or bad. The abstract class author has imposed structure on you. Depending on the cleverness of the author of the abstract class, this may be good or bad. Another issue that's important is what I call "heterogeneous vs. homogeneous." If implementors / subclasses are homogeneous, tend towards An Abstract Base Class. If The is getOGeneous, Use ANTERFACE. (Now All I Have to do is com up with a good definition of hetero / homo-generation in this context.) IF The Various Objects Are All of-a-a-kind , and share a common state and behavior, then tend towards a common base class. If all they share is a set of method signatures, then tend towards an interface.HomogeneityIf all the various implementations share is the method signatures, then an interface works best .If the v Arious Implementations Are All of a Kind and Share A Common Status and Behavior, USUALLY An Abstract Class Works Best.maintenanceValign = "TOP"
