Which is more usefull Abstract Class or Interface and Why?
-
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.
-
In programming point of view Which is more usefull Abstract Class or Interface and Why?
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
-
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..
