Click here to Skip to main content
12,760,662 members (35,625 online)
Rate this:
Please Sign up or sign in to vote.
See more: .NET OOP
Hi all,

If an abstract class and an interface have same members without body methods then what is the difference between them.

Posted 31-Mar-11 22:42pm
Updated 1-Apr-11 2:10am
Henry Minute225.5K
apaka 1-Apr-11 3:46am
Try this article
Amit Kumar Tiwari 1-Apr-11 3:47am
Abstract class still has an option of defining the methods at later stage, whereas interfaces dont.
Rate this: bad
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[^]
SAKryukov 1-Apr-11 5:27am
Sure, my 5.
And I referenced our past discussion, it was useful.
Albin Abel 1-Apr-11 6:44am
Good link. my 5
Brijesh Kr 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 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 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 1-Apr-11 7:09am
A very good link. my 5
deveoper12345 24-Aug-14 21:25pm
Thanks All for your valuable time and guidance.
OriginalGriff 25-Aug-14 2:01am
You're welcome!
Rate this: bad
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...?.

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).

Albin Abel 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 1-Apr-11 11:12am
Thank you, Albin.
CPallini 1-Apr-11 7:06am
As you well know the 'interfaces' are the toy language expedient for mocking multiple inheritance...
***** **
** *** *
** *** *
***** **
SAKryukov 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++.

CPallini 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 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? :-)
Rate this: bad
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.

SAKryukov 1-Apr-11 11:17am
Excellent. My 5.
Albin Abel 1-Apr-11 12:50pm
Thanks SAKryukov
Rate this: bad
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.
Albin Abel 1-Apr-11 12:49pm
What you mean by 1. Interface is Globally accessible but Abstract class is not.?
SAKryukov 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.
Albin Abel 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 2-Apr-11 16:24pm
I would say it is invalid as formulated. May be the indent was different.
Albin Abel 3-Apr-11 0:20am
May be, Yes
Brijesh Kr 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.
Albin Abel 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 2-Apr-11 3:02am
Thanks, let me see.
OriginalGriff 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
Top Experts
Last 24hrsThis month

Advertise | Privacy | Mobile
Web02 | 2.8.170217.1 | Last Updated 22 Mar 2015
Copyright © CodeProject, 1999-2017
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100