Java Interface VS Abstrace Class 的对比

When should you use an abstract class, when an interface, when both? Thistable may help you decide.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 upwith a good definition of hetero/homo-geneous in this context.) If the variousobjects are all of-a-kind, and share a common state and behavior, then tendtowards a common base class. If all they share is a set of method signatures,then tend towards an interface.
Interfaces vs Abstact 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 just stubsthat have to be overridden.
constants	Static final constants only, can use them without qualification in classesthat implement the interface. On the other paw, these unqualified names pollutethe namespace. You can use them and it is not obvious where they are coming fromsince the qualification is optional.	Both instance and static constants are possible. Both static and instanceintialiser code are also possible to compute the constants.
third party convenience	An 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-do	Interfaces are often used to describe the peripheral abilities of a class,not its central identity, e.g. an Automobile classmight implement the Recyclable interface, whichcould apply to many otherwise totally unrelated objects.	An abstract class defines the core identity of its descendants. If youdefined a Dog abstract class then Damamation descendants are Dogs, theyare not merely dogable. Implemented interfaces enumerate the general things aclass can do, not the things a class is. In a Java context, users should typically implement the Runnable interfacerather than extending Thread, because they're notreally interested in providing some new Threadfunctionality, they normally just want some code to have the capability ofrunning independently. They want to create something that can be run in a thread,not a new kind of thread.The similar is-a vs has-a debate comes up when youdecide to inherit or delegate. multipleinheritance 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 youimplement the inteface, you start from scratch without any defaultimplementation. You have to obtain your tools from other classes; nothing comeswith 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 imposed structureon you. Depending on the cleverness of the author of the abstract class, thismay be good or bad.
homogeneity	If all the various implementaions share is the method signatures, then aninterface works best.	If the various implementations are all of a kind and share a common statusand behaviour, usually an abstract class works best.
maintenance	If your client code talks only in terms of an interface, you can easilychange the concrete implementation behind it, using a factorymethod.	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 theactual class. Modern JVMs are discovering ways to reduce this speed penalty.	Fast
terseness	The constant declarations in an interface are all presumed publicstatic final, so you may leave that part out. You can't call any methodsto compute the initial values of your constants. You need not declare individualmethods 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 ofyour constants and variables, both instance and static. You must declare all theindividual 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 continueto work without change.