Monday, January 7, 2008

Abstract VS Interface

multiple inheritance
INTERFACE-A class may implement several interfaces.
ABSTRACT-A class may extend only one abstract class.

default implementation
INTERFACE- cannot provide any code at all, much less default code.
ABSTRACT- can provide complete code, default code, and/or just stubs that have to be overridden.

is-a vs -able or can-do
INTERFACE- 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 otherwise totally unrelated objects.
ABSTRACT-defines the core identity of its descendants. If you defined a Dog abstract class then Datamation descendants are Dogs, they are not merely dog able. Implemented interfaces enumerate the general things a class can do, not the things a class is.

plug-in
INTERFACE- You can write a new replacement module for an interface that contains not one stick of code in common with the existing implementations. When you implement the interface, you start from scratch without any default implementation. 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.
ABSTRACT-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.

homogeneity
INTERFACE- If all the various implementations share is the method signatures, then an interface works best.
ABSTRACT-If the various implementations are all of a kind and share a common status and behaviour, usually an abstract class works best. Another issue that’s important is what I call "heterogeneous vs. homogeneous." If implementors/subclasses are homogeneous, tend towards an abstract 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-generous in this context.) If the various objects are all of-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.

maintenance
INTERFACE- If your client code talks only in terms of an interface, you can easily change the concrete implementation behind it, using a factory method.
ABSTRACT- Just like an interface, if your client code talks only in terms of an abstract class, you can easily change the concrete implementation behind it, using a factory method.

adding functionality
INTERFACE- If you add a new method to an interface, you must track down all implementations of that interface in the universe and provide them with a concrete implementation of that method.
ABSTRACT- If you add a new method to an abstract class, you have the option of providing a default implementation of it. Then all existing code will continue to work without change.

No comments: