-----------------------------------------------------------

New Message on BDOTNET

-----------------------------------------------------------
From: ksnaveen
Message 3 in Discussion

Hi...   I have seen many posts asking difference between Interfaces & abstract 
classes.. I prepared a table hope this will make clear both terms and this table will 
help you decide where one should it use.   I would be soon posting this as a document 
and will upload into BDOT.NET as well as Chennai user groups.   If you have any more 
queries do revert back. Hope this will help.   Cheers!!!!
Nave www.ksnaveen.blogspot.com  
  
  
Interface vs abstract class <o:p></o:p> 
 <o:p></o:p> 
 <o:p></o:p>     
Interfaces vs Abstract Classes <o:p></o:p>   
Feature <o:p></o:p>  
Interface <o:p></o:p>  
Abstract class <o:p></o:p>   
Multiple inheritance <o:p></o:p>  
A class may implement several interfaces. <o:p></o:p>  
A class may extend only one abstract class. <o:p></o:p>   
Default implementation <o:p></o:p>  
An interface cannot provide any code at all, much less default code. <o:p></o:p>  
An abstract class can provide complete code, default code, and/or just stubs that have 
to be overridden. <o:p></o:p>   
Constants <o:p></o:p>  
Static 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. <o:p></o:p>  
Both instance and static constants are possible. Both static and instance intialiser 
code are also possible to compute the constants. <o:p></o:p>   
Third party convenience <o:p></o:p>  
An interface implementation may be added to any existing third party class. 
<o:p></o:p>  
A third party class must be rewritten to extend only from the abstract class. 
<o:p></o:p>   
is-a vs -able or can-do <o:p></o:p>  
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 otherwise totally unrelated objects. <o:p></o:p>  
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-in <o:p></o:p>  
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. <o:p></o:p> 
 
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 they 
are heterogeneous, use an interface. (Now all I have to do is come up with a good 
definition of hetero/homo-geneous 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. <o:p></o:p>   
Homogeneity <o:p></o:p>  
If all the various implementations share is the method signatures, then an interface 
works best. <o:p></o:p>  
If the various implementations are all of a kind and share a common status and 
behavior, usually an abstract class works best. <o:p></o:p>   
Maintenance <o:p></o:p>  
If your client code talks only in terms of an interface, you can easily change the 
concrete implementation behind it, using a factory method. <o:p></o:p>  
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. 
<o:p></o:p>   
Speed <o:p></o:p>  
Slow, requires extra indirection to find the corresponding method in the actual class. 
Modern JVMs are discovering ways to reduce this speed penalty. <o:p></o:p>  
Fast <o:p></o:p>   
Terseness <o:p></o:p>  
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 to compute the initial values of 
your constants. You need not declare individual methods of an interface abstract. They 
are all presumed so. <o:p></o:p>  
You can put shared code into an abstract class, where you cannot into an interface. If 
interfaces want to share code, you will have to write other bubblegum to arrange that. 
You may use methods to compute the initial values of your constants and variables, 
both instance and static. You must declare all the individual methods of an abstract 
class abstract. <o:p></o:p>   
Adding functionality <o:p></o:p>  
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. <o:p></o:p>  
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. <o:p></o:p> 
 <o:p></o:p> 
 <o:p></o:p>

-----------------------------------------------------------

To stop getting this e-mail, or change how often it arrives, go to your E-mail 
Settings.
http://groups.msn.com/BDotNet/_emailsettings.msnw

Need help? If you've forgotten your password, please go to Passport Member Services.
http://groups.msn.com/_passportredir.msnw?ppmprop=help

For other questions or feedback, go to our Contact Us page.
http://groups.msn.com/contact

If you do not want to receive future e-mail from this MSN group, or if you received 
this message by mistake, please click the "Remove" link below. On the pre-addressed 
e-mail message that opens, simply click "Send". Your e-mail address will be deleted 
from this group's mailing list.
mailto:[EMAIL PROTECTED]

Reply via email to