Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: .NEToops
Hi all,
 
If an abstract class and an interface have same members without body methods then what is the difference between them.
 
Thanks
Posted 31-Mar-11 21:42pm
Edited 1-Apr-11 1:10am
Henry Minute223.2K
v4
Comments
apaka at 1-Apr-11 3:46am
   
Try this article http://www.codeproject.com/KB/cs/abstractsvsinterfaces.aspx
Amit Kumar Tiwari at 1-Apr-11 3:47am
   
Abstract class still has an option of defining the methods at later stage, whereas interfaces dont.
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

There is an article which covers this in some depth here: Abstract Class versus Interface[^]
  Permalink  
Comments
SAKryukov at 1-Apr-11 5:27am
   
Sure, my 5.
And I referenced our past discussion, it was useful.
--SA
Albin Abel at 1-Apr-11 6:44am
   
Good link. my 5
Brijesh Kr at 1-Apr-11 22:54pm
   
This is only a link.
Why you people make things complex even when it can be understood by some lines. OP does not know the difference and you are giving the link. "Thats wonder".... ha
Albin Abel at 2-Apr-11 0:59am
   
See my comment on your answer. You need to learn. Thats why the link. You can see your few lines does not work well every time, but misleading.
OriginalGriff at 2-Apr-11 3:32am
   
I give the link because it is a complex subject, and needs some careful handling. You can do a lot more in an article than you can in a Q&A answer - images for example - which can make the discussion of complicated subjects easier to understand.
If I just wrote a simple explanation here myself, it would be just that: simple. The topic deserves more than that.
avigodse at 1-Apr-11 7:09am
   
A very good link. my 5
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 2

In addition to the reference by Griff, please read this discussion: When we use abstract and when we use interface...?[^].
 
[EDIT]
One more important thing: in .NET structures cannot inherit from non-interfaces. They can implement muliple interfaces though. This is practically the only OOP feature applied to structures (and value types in general). Most developers did not pay attention to this important feature (unfortunatly, including myself, until someone brought my attention to it).
 
—SA
  Permalink  
v2
Comments
Albin Abel at 1-Apr-11 6:44am
   
Good discussion. My 5. I have added few more discussion here. So the discussions accumulate and the link refresh for future answers. :). My 5
SAKryukov at 1-Apr-11 11:12am
   
Thank you, Albin.
--SA
CPallini at 1-Apr-11 7:06am
   
As you well know the 'interfaces' are the toy language expedient for mocking multiple inheritance...
***** **
** *** *
** *** *
***** **
SAKryukov at 1-Apr-11 11:16am
   
I think the talking about "toy" and "real" languages have not rational background and only shows your imprinting by "the one which should not be named" :-).
 
What is really good to remember is that COM interface was modelled over a C++ classs without data with all pure virtual method (call it "purely abstract class"); and this form is currently used to support interfaces in C++.
 
--SA
CPallini at 1-Apr-11 13:10pm
   
Well, of course I don't think C# and Java are toy languages. That said, C++ has interfaces (yes, pure abstract classes are interfaces). COM, on the other hand was a (brilliant if you ask me) attempt to share native objects among languages.
SAKryukov at 1-Apr-11 13:26pm
   
From the other hand, I agree most of the languages are not good, but not to be classified into "real" and "toy".
Naturally, I would prefer to be "brilliant", so I'm asking you: what do you mean here? :-)
--SA
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 3

I hope the links given by SAKryukov and Original Griff give you a clear picture. I am agree with the comment of Amit Kumar Tiwari. But the point I am stress here is there is no hard rule which one to use. It depends on your necessity. Let me give you a situation which favors Interface over Abstract.
 
Let us say you have a class Car. It has an abstract method? CalcFuelEfficinecy. Then you will end up defining this method in all your child classes, even the method is same for a few of those children. You can visualize repeatability of same code. As a rescue you want to move this method to your abstract class?. Can't right as a few children want this method in a different way. May be you end up messing with overloading.
 
But one thing clear this has to taken out of the class and deal separately. So how about defining a IEfficiencyCalculator and it has a signature for the CalcFuelEfficiency method?. Then interface will be implemented by a set of classes say EfficiencyCalculator1, EfficiencyCalculator2.... and so on. Now you can have a instance member of this interface type in your parent class and assign the required EfficiencyCalculator at runtime.. You can see now the problem solved and you can have any number of efficiency calculation business logics and same business logic not repeated. This pattern otherwise called a strategy pattern. You don't need to have a abstract class again to defined these strategy composites. Because here we only define a contract. A class needed only when we use the oops concepts like encapsulation, inheritance etc.,
 
Now coming back to Amit Kumar Tiwari's comment. An abstract class allows defining a method later stage. Agreed. This is an advantage or disadvantage?, I think it depends your requirement again. If you are going to implement/define this new method in the abstract class then I see there is a potential problem. From the example the Car inherited by Car1. Later you add a method to Car, of course it is useful method for many children, but not required for car1. So you must override this in car1 and do nothing, otherwise the classes inherit car1 will access this method and misuse it. But this problem not there in interfaces. It ensures a safe contract.
 
Again coming back to Amit Kumar Tiwari's comment that abstract class favors adding new method. Good point. But how to use it for flexibility. Define the interface as said earlier. Use an abstract class and abstract methods to implement this interface. Then only necessary methods can be implemented in the children. So when you add new method in interface , then the least change we need to do only at the abstract class and the necessary children. Other children not affected. So interface still offers the flexibility to add new methods at later stage in a safer way than the inheritance path.
 
Cheers!
  Permalink  
v2
Comments
SAKryukov at 1-Apr-11 11:17am
   
Excellent. My 5.
--SA
Albin Abel at 1-Apr-11 12:50pm
   
Thanks SAKryukov
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 4

Differences are as Follows:
1. Interface is Globally accessible but Abstract class is not.
2. Abstract class can have a method with Body but not an interface.
3. Abstract class can have a abstract or non-abstract method but methods in Interface are abstract by-default.
4. All Methods in Interface are public by-default but not in abstract.
5. Abstract class can have methods or attribute but interface cannot have an attribute.
  Permalink  
v2
Comments
Albin Abel at 1-Apr-11 12:49pm
   
What you mean by 1. Interface is Globally accessible but Abstract class is not.?
SAKryukov at 1-Apr-11 13:01pm
   
Igree. It probably does not make sense.
 
I recently added important item I did not pay attention for: structures can implement interfaces!
My Answer updated.
--SA
Albin Abel at 2-Apr-11 0:48am
   
Thanks for the information about structures. Brijesh's first point is still questionable. His explanation for global accessible is access across applications. But interfaces by default marked internal. So I am not sure about the validity of his first point.
SAKryukov at 2-Apr-11 16:24pm
   
I would say it is invalid as formulated. May be the indent was different.
--SA
Albin Abel at 3-Apr-11 0:20am
   
May be, Yes
Brijesh Kr at 1-Apr-11 22:38pm
   
That mean, Interface can be accessible out side of Application.
A class shows Such behaviour only when it is declared public.
Thank
Albin Abel at 2-Apr-11 0:45am
   
That simply mean interfaces are public, classes have choices. But you are wrong. Interface accepts the internal scope, Interfaces are internal by default. So you have to explicitly define Public on a interface to access it across application. So is that different from a class marked as public?!!.
Brijesh Kr at 2-Apr-11 3:02am
   
Thanks, let me see.
OriginalGriff at 2-Apr-11 3:34am
   
You see what I mean, about giving a link? Sometimes, people have to actually read the explanation, rather than a list of bullet points! :laugh:

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
0 Sergey Alexandrovich Kryukov 718
1 OriginalGriff 421
2 Tadit Dash 355
3 sanket saxena 329
4 Peter Leow 193
0 Sergey Alexandrovich Kryukov 12,109
1 OriginalGriff 7,326
2 Peter Leow 5,003
3 Abhinav S 4,003
4 Maciej Los 3,575


Advertise | Privacy | Mobile
Web01 | 2.8.140421.2 | Last Updated 1 Apr 2011
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Use
Layout: fixed | fluid