interfaces

[abcd]

Can someone tell me whats the exact advantage of Interfaces in C#. To me
abstract classes serves the purpose and have all good things then what is
special about interfaces...can someone tell me some real example from
system, user, developer point of view....

 

[cody]

Can someone tell me whats the exact advantage of Interfaces in C#. To me
abstract classes serves the purpose and have all good things then what is
special about interfaces...can someone tell me some real example from
system, user, developer point of view....

You can implement many interfaces in a class but only have one single
base-class.

Also an interface doesn't force you to make the methods virtual/override.

Additionally all methods for an interface have to be public.

 

[Bruce Wood]

Can someone tell me whats the exact advantage of Interfaces in C#. To me
abstract classes serves the purpose and have all good things then what is
special about interfaces...can someone tell me some real example from
system, user, developer point of view....

Try reading this thread:

http://groups.google.com/group/micr...ges.csharp/browse_frm/thread/fd667cc111cc960b

 

[Aneesh Pulukkul[MCSD.Net]]

Try reading this thread:

http://groups.google.com/group/microsoft.public.dotnet.languages.csha...

Basicallly we need interfaces when there is a need to have similiar
methods with different implementations spanning across multple
classes. If you are dealing with implementation in one class then
abstract classes are enough. But when we need different implementation
for similiar methods we can use interfaces. For e.g consider
peripheral properties - we have Move() method for Vehicle and Animal.
But the implementations are different for the same methd Move() in
both classes.

 

[Dylan Parry]

Can someone tell me whats the exact advantage of Interfaces in C#. To me
abstract classes serves the purpose and have all good things then what is
special about interfaces.

The two ideas say very different things. Inheriting from an abstract
class simply says that your class "is a ..." whereas implementing an
interface says "my class will do ..."

As mentioned by Cody elsewhere in this thread, C# doesn't support
multiple inheritance, so you can only inherit from one abstract class at
a time; but you can implement as many interfaces as you like.

For example, if you are creating a "Dog" class you might inherit from
the abstract class "Animal" and implement the interfaces "IBark" and
"IChaseParkedCars"; but you wouldn't be able to do that if "IBark" and
"IChaseParkedCars" were abstract classes rather than interfaces.

--
Dylan Parry
http://electricfreedom.org | http://webpageworkshop.co.uk

The opinions stated above are not necessarily representative of
those of my cats. All opinions expressed are entirely your own.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Can someone tell me whats the exact advantage of Interfaces in C#. To me
abstract classes serves the purpose and have all good things then what is
special about interfaces...can someone tell me some real example from
system, user, developer point of view....

Since you can only have one base class Interfaces is what allow a class to
implement more than one ,well interface

 

[Barfy the Wonder Camel]

Can someone tell me whats the exact advantage of Interfaces in C#. To me
abstract classes serves the purpose and have all good things then what is
special about interfaces...can someone tell me some real example from
system, user, developer point of view....

An interface will allow you to publish a standard, um, interface, for
making use of a functionality. For instance, you may write a sorting
library, and you want it to be generally available to other classes.
You publish an interface, consisting of a set of functions, that
classes have to implement in order to be able to use your library. Or
if you want your class to be able to implement BeginInvoke and
EndInvoke, you have to implement the ISynchronizeInvoke interface.
Implementing just means you have to supply a version of the functions
defined by the interface within your class.

..NET implements a number of interfaces, all of which start with "I",
as in IComparable, ICollection, etc. Classes that implement the
interface can use the functionality.

So if you are writing a class "smee" that you want to be able to sort,
use asynchronous communications, and serialize to a file (or
something), you'd define it as

class smee : IComparable, ISynchronizeInvoke, ISerializable {}

and implement all the required methods for those interfaces, then you
can hand a smee to any method that requires one of those interfaces.

 

[Ben Voigt [C++ MVP]]

An interface will allow you to publish a standard, um, interface, for
making use of a functionality. For instance, you may write a sorting

An abstract class allows this as well.

library, and you want it to be generally available to other classes.
You publish an interface, consisting of a set of functions, that
classes have to implement in order to be able to use your library. Or
if you want your class to be able to implement BeginInvoke and
EndInvoke, you have to implement the ISynchronizeInvoke interface.
Implementing just means you have to supply a version of the functions
defined by the interface within your class.

.NET implements a number of interfaces, all of which start with "I",
as in IComparable, ICollection, etc. Classes that implement the
interface can use the functionality.

So if you are writing a class "smee" that you want to be able to sort,
use asynchronous communications, and serialize to a file (or
something), you'd define it as

class smee : IComparable, ISynchronizeInvoke, ISerializable {}

and implement all the required methods for those interfaces, then you
can hand a smee to any method that requires one of those interfaces.

Again, an abstract class works the same, except that abstract classes are
far more powerful. However, .NET limits base classes to single inheritance,
but allows multiple interfaces in the base list.

 

[Mark Wilden]

The two ideas say very different things. Inheriting from an abstract
class simply says that your class "is a ..." whereas implementing an
interface says "my class will do ..."

I think both are is-a relationship. If you implement IDisposeable, then your
class is-an IDisposeable, in the Liskov sense of being about to use objects
of that class whenever an IDisposeable is expected.

///ark

 

[Aneesh Pulukkul[MCSD.Net]]

I think both are is-a relationship. If you implement IDisposeable, then your
class is-an IDisposeable, in the Liskov sense of being about to use objects
of that class whenever an IDisposeable is expected.

///ark

I don't think both are the same - "is" relation between base class-

derived class and interface->implemented class.

In inheritance it would seem ok. But in case of interfaces it's more
like "implements" some methods.

 

[Aneesh Pulukkul[MCSD.Net]]

I don't think both are the same - "is" relation between base class->derived class and interface->implemented class.

In inheritance it would seem ok. But in case of interfaces it's more
like "implements" some methods.

MSDN recommendations:
http://msdn2.microsoft.com/en-us/library/scsyfw1d(VS.71).aspx

 

[Mark Wilden]

I don't think both are the same - "is" relation between base class-
In inheritance it would seem ok. But in case of interfaces it's more
like "implements" some methods.

To a user of an object, who is expecting an IInterface, any object that
implements IInterface is the same as any other.

Also remember that every class defines an interface. The C# "interface"
construct simply says that that's -all- it defines.

The important point of is-a (in my mind) is substitutability.

///ark

 

[Bruce Wood]

To a user of an object, who is expecting an IInterface, any object that
implements IInterface is the same as any other.

Also remember that every class defines an interface. The C# "interface"
construct simply says that that's -all- it defines.

The important point of is-a (in my mind) is substitutability.

///ark

Sorry, I strongly disagree.

The important point of "is-a" is classification.

The important point of an interface is to establish a contract or a
capability, for substitutability (as you said) or polymorphism
(another word for same).

 

[Ben Voigt [C++ MVP]]

To a user of an object, who is expecting an IInterface, any object that
implements IInterface is the same as any other.

Also remember that every class defines an interface. The C# "interface"
construct simply says that that's -all- it defines.

The important point of is-a (in my mind) is substitutability.

That, and interface implementation *is* inheritance.

 

[Mark Wilden]

The important point of "is-a" is classification.

My feeling is that if one type "is-a" nother type, then the first type can
be substituted for the second. Does this run afoul of other definitions of
"is-a"?

Classification, on the other hand, means "is-like-a," because if a type
really "was-a" nother type, then they'd be the same type. "Is-a" really
means "can-be-used-as-a," otherwise, there'd be no practical reason for it.

///ark

 

[Mark Wilden]

That, and interface implementation *is* inheritance.

I don't follow. Clearly, implementations of an interface are substitutable
for each other. But they're not related by inheritance.

///ark

 

[Bruce Wood]

My feeling is that if one type "is-a" nother type, then the first type can
be substituted for the second. Does this run afoul of other definitions of
"is-a"?

I don't know about "runs afoul," but I'm not sure what it means. It
doesn't sound right to me, but then I'm struggling to imagine the
precise meaning of it.

"is-a" to me implies classification into more and more general
categories, or, going in the other direction, specialization into more
and more specific types. So, for example, a Duck "is-a" Bird, in the
sense that the statement "All ducks are birds" is an accurate one.

Interfaces do not imply this sort of relationship. If you define an
interface that is then implemented by many diverse classes, you cannot
say that the all members of the class "are" of that interface. Usually
one talks in terms of capabilities, and the interface names reflect
that, so "All ducks can quack," or "All ducks can fly."

 

[Mark Wilden]

If you define an
interface that is then implemented by many diverse classes, you cannot
say that the all members of the class "are" of that interface.

As far as clients of that interface are concerned, all classes that
implement the interface are the same.

It seems to me that the only difference between an abstract class and an
interface is that an abstract class can contain implementation, and an
interface cannot. There's also multiple inheritance, and the fact that an
interface can't derive from a class, but I don't think that's germaine to
"is-a." Is there another difference that I'm missing, that would relate to
"is-a"? I don't mean a difference in intent, but a difference in what the
two constructs actually do.

I think it's important to note that all classes define an interface, hence a
contract that must be maintained by any derivative. In that sense, I would
say that a class "is-a" interface.

///ark

 

[Jon Skeet [C# MVP]]

It seems to me that the only difference between an abstract class and an
interface is that an abstract class can contain implementation, and an
interface cannot. There's also multiple inheritance, and the fact that an
interface can't derive from a class, but I don't think that's germaine to
"is-a." Is there another difference that I'm missing, that would relate to
"is-a"? I don't mean a difference in intent, but a difference in what the
two constructs actually do.

Two extra differences which don't affect the "is-a" but should be on
the list for completeness:

1) Structs can implement interfaces
2) Abstract classes can't be proxied by RealProxy unless they derive
from MarshalByRefObject (IIRC)