Which is more usefull Abstract Class or Interface and Why?
-
In programming point of view Which is more usefull Abstract Class or Interface and Why?
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 -
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.
-
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.
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
-
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.
Until I can find the citation, I've struck through the section.
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
-
Until I can find the citation, I've struck through the section.
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
-
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'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
-
Until I can find the citation, I've struck through the section.
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
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.....
-
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.
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
-
In programming point of view Which is more usefull Abstract Class or Interface and Why?
If I could have only one, I'd pick interface. I won't tell you why.
-
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.
-
In programming point of view Which is more usefull Abstract Class or Interface and Why?
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.
-
In programming point of view Which is more usefull Abstract Class or Interface and Why?
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.
Sort of a cross between Lawrence of Arabia and Dilbert.[^]
-Or-
A Dead ringer for Kate Winslett[^] -
If I could have only one, I'd pick interface. I won't tell you why.
:laugh: Me too, but I won't say why either!
Sort of a cross between Lawrence of Arabia and Dilbert.[^]
-Or-
A Dead ringer for Kate Winslett[^] -
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.
Sort of a cross between Lawrence of Arabia and Dilbert.[^]
-Or-
A Dead ringer for Kate Winslett[^]Plums. There are just some times when you have to say plums.
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
-
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
Good one..
