|
They're both useful. They do something different.
Abstract classes can define fields and implement methods, but a class can only derive from one of them and a struct can not derive from them.
Interfaces can only define method signatures (including properties, indexers etc), but classes and structs can implement as many of them as they want.
|
|
|
|
|
An abstract class is generally useful when you are providing a partially or almost functional class, but you require certain things to be overridden to make it fully functional. For example, although they didn't, it would have made sense for Microsoft to make UserControl abstract and make its OnPaint method abstract. Or in my game lobby[^], the BaseLobby is abstract to provide some reusable code to both client and server.
An interface is generally useful when you want otherwise not directly related classes (i.e. they are not part of the same inheritance tree within your code, e.g. two custom controls, or a 'view' in MVC parlance that displays to the screen and one which sends information down a network) to expose common functionality. An interface can be used to 'patch in' functionality into objects that already have an inheritance tree. For example the interface INotifyPropertyChanged – any type of object can be declared to be the source of notification events, without any reason to restrict it to one part of the inheritance branch.
The functionality you're trying to patch in is usually small, most interfaces will only be a few methods, though there are some dubious cases in the framework. (Why would you want to implement IList<T> from scratch, for example?) The downside of an interface is that you need to implement all the methods (and properties) yourself in each class that implements it, which is why they should be simple.
So the short answer is: both, depending on what you want to do.
|
|
|
|
|
Abstract Class or Interface are different for working.
You can use only one abstract class with any class. But u can use multiple interface.
You can use concrete method or properties with abstract class. but this facility is not available with interface.
If you can think then I Can.
|
|
|
|
|
This really smells like a homework question to me.
A way to think about it. An interface is a contract. It states that your class will have certain elements, but it puts no constraints on how they will be achieved. An abstract class defines some common functionality that you can override and extend as appropriate.
With an interface, you can cast an object to the interface (providing it implements it), and call the functionality on it. This is how IDisposable works with the using statement. Effectively, the following code
(using Myclass c = new Myclass())
{
}translates to
Myclass c = null;
try
{
}
finally
{
((IDisposable)c).Dispose();
}Now, you said "In programming", so there's an additional consideration to take into account. In C#, you cannot have multiple inheritance (where you can in C++). What you can do in C# though, is support multiple interface implementation, so your class can inherit from one class but you can implement many interfaces. You note that I said, in C#, there. There's a common misconception that you can't do multiple inheritance in .NET. That's not true. The constraint is put in place by the language, and not the runtime, so if a .NET language chose to allow multiple inheritance, that would be supported. Until I can find the citation for this, please disregard this statement (it's from a very old interview, so it's taking me some time to find it).
I'm not a stalker, I just know things. Oh by the way, you're out of milk. Forgive your enemies - it messes with their heads
My blog | My articles | MoXAML PowerToys | Onyx
modified on Thursday, April 14, 2011 8:22 AM
|
|
|
|
|
Pete O'Hanlon wrote: There's a common misconception that you can't do multiple inheritance in .NET. That's not true. The constraint is put in place by the language, and not the runtime, so if a .NET language chose to allow multiple inheritance, that would be supported.
Not sure where you get that, but ECMA 335 (the CLI spec, not the C# spec) has this to say about it on page 161/556:
The extends keyword specifies the base type of a type. A type shall extend from exactly one other type. If no type is specified, ilasm will add an extends clause to make the type inherit from System.Object.
|
|
|
|
|
David1987 wrote: Not sure where you get that, but ECMA 335 (the CLI spec, not the C# spec) has
this to say about it on page 161/556:
It's from an interview that Anders made around about 2002. I'll have a hunt round and see if I can find it.
|
|
|
|
|
Until I can find the citation, I've struck through the section.
|
|
|
|
|
Ok, well, please find it 
This is rather odd so I'd prefer to get to the bottom of it
|
|
|
|
|
It could be that Anders said that while the underlying framework would support it, they made it so that the CLI inhibited it. I'm operating off an old memory here (I probably read this about 8 years ago).
|
|
|
|
|
I tried this in CIL :
.assembly extern mscorlib
{
.publickeytoken = (B7 7A 5C 56 19 34 E0 89)
.ver 4:0:0:0
}
.assembly CILTypes
{
.ver 1:0:0:0
}
.module CILTypes.dll
.namespace MyCompany
{
.namespace MyNameSpace
{
.class public interface IMyInterface {}
.class public MyBaseClass
{
}
.class public MyAnotherBaseClass
{
}
.class public MyDerivedClass
extends MyCompany.MyNameSpace.MyBaseClass
extends MyCompany.MyNameSpace.MyNotherBaseClass
implements MyCompany.MyNameSpace.IMyInterface
{
}
}
}
and the compiler throws this error
MyBaseClass.il(30) : error : syntax error at token 'extends' in : extends myCompany.MyNameSpace.MyBaseClass. So I guess it would be a restriction on all .Net languages.
...and I have extensive experience writing computer code, including OIC, BTW, BRB, IMHO, LMAO, ROFL, TTYL.....
|
|
|
|
|
As I just said, it could be that Anders said that they imposed this restriction in the CLI. He definitely said that they could extend it to do it if they had to, but he saw no compelling reason to do so, and about a thousand arguments against. Once I find the interview, I'll post the link.
|
|
|
|
|
|
Sounds like a homework question. It's a subjective call based on the context of the code. Both have their uses and both are better than the other within a specific context.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
If I could have only one, I'd pick interface. I won't tell you why.
|
|
|
|
|
PIEBALDconsult wrote: I won't tell you why
Let me guess, you're a concrete guy.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Me too, but I won't say why either!
|
|
|
|
|
You can answer that yourself; just take an existing app that uses both, then try and rewrite it once without using abstract classes, and once without using interfaces. I trust you will never forget the conclusions.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Tell your lecturer from me that is an imbicile question. It is like saying which is fruitiest, apples or oranges. Both are useful, both have a specific job to do.
|
|
|
|
|
Plums.
There are just some times when you have to say plums.
|
|
|
|
|
Hey how many of you don't know about LinkedList<t>?[^]
It's been available since .NET 2!! And I missed it seems like it's not been discussed a lot. In fact many discussions omitted such important class.[^]
Any specific article which discuss and compare among various .NET collection classes now in terms of fetch-by-key/insert/remove/add/memory allocation/performance (polynomial time, linear time...etc) similar to cplusplus.com[^]
Gosh how the hell did I miss such important subject.
REF 1: MSDN Chapter 5 — Improving Managed Code Performance
- no reference of LinkedList but ListDictionary[^]
REF 2: That's more like it... read this comparison.[^] My question for this article is, "Insert" -- are they refering to "insert in middle of the list"? Of "Add" which adds to end of list? But, for example, for Dictionary<x,y> only supports "Add", there's no such thing as "Insert". "Insert" is supported by "IList<t>" however. Seems like article did not distinguish between add and insert.
REF 3: This seems to be the winner!![^]
Anything else?
Anyway, seems like 99% of applications we got by with Generic List/Dictionary (reasonable performance no op exceeds polynomial time) without LinkedList (all good except lookup). Does anybody has a good scenario as an example where they'd need LinkedList?
dev
modified on Wednesday, April 13, 2011 10:31 PM
|
|
|
|
|
It looks like you are the only person who hadn't noticed - why did it take you so long?
Linked list are useful, yes. But there are other structures that are more useful, depending on your circumstances:
Queue[^]
Stack[^]
HashSet[^]
To name but three.
There is a list of all the generic collections under the System.Collections.Generic Namespace[^]
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
Manfred R. Bihy: "Looks as if OP is learning resistant."
|
|
|
|
|
"It looks like you are the only person who hadn't noticed - why did it take you so long?"
> because i first started with .NET 1 and didn't have more time at work than "Deliver"
dev
|
|
|
|
|
devvvy wrote: didn't have more time at work than "Deliver"
Get used to that!
Update your skills outside work - that way you may be able to get a better job: if you never upgrade your skills you pretty definitely won't!
Some employers are interested in keeping employees current because it helps the employee and the company. Others are just out to screw everything they can from you, and then discard the dried out husk "because you don't know the technology we are moving into". Get away from the later as fast as you can!
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
Manfred R. Bihy: "Looks as if OP is learning resistant."
|
|
|
|
|
err... mate, if you don't have an answer, try not to answer.
dev
|
|
|
|
|
Since you didn't post a question, I didn't answer it...
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
Manfred R. Bihy: "Looks as if OP is learning resistant."
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
