By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,906 Members | 1,771 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,906 IT Pros & Developers. It's quick & easy.

IClass for Interface: what's an interface?

P: n/a
Aren't all classes interfaces?

What constitutes an interface (and with it, the "I" prefix
distinction)?

Zytan

Feb 28 '07 #1
Share this Question
Share on Google+
17 Replies


P: n/a
Hi,

"Zytan" <zy**********@yahoo.comwrote in message
news:11**********************@a75g2000cwd.googlegr oups.com...
Aren't all classes interfaces?
All classes define (at least) one interface. But they are not the same.
What constitutes an interface (and with it, the "I" prefix
distinction)?
An interface is a contract. It means that any class that implement it has to
implement all the members declared in it.

Take a look at MSDN for a better more in depht explanation

Feb 28 '07 #2

P: n/a
Aren't all classes interfaces?
>
All classes define (at least) one interface. But they are not the same.
You mean, the word 'interface' has two meanings?
What constitutes an interface (and with it, the "I" prefix
distinction)?

An interface is a contract. It means that any class that implement it has to
implement all the members declared in it.
Unfortunately, knowing nothing about it, I don't follow this at all.
Are you talking about inheritance?
Take a look at MSDN for a better more in depht explanation
I tried, but there are so many interfaces in MSDN, it's hard to find a
simple explanation. I guess I'll have to dig in and read about one in
general. I find MSDN (mostly) very useless except as a reference.
That is, it doesn't help someone unless they sort of already know.
This was a particular known problem the help guys were supposed to fix
for v2005.

Zytan

Feb 28 '07 #3

P: n/a
On 28 Feb 2007 13:35:34 -0800, "Zytan" <zy**********@yahoo.comwrote:
>Aren't all classes interfaces?

What constitutes an interface (and with it, the "I" prefix
distinction)?

Zytan
An interface is a class (or struct). It contains methods, properties,
indexers or events. It does not provide implementations for any of
its methods.

The advantage of an interface is that any other class (or interface)
can "inherit" (or implement) that interface. It is the C# way to get
something similar to multiple inheritance in C++. Any class that
implements an interface must supply all the members specified in the
interface.

rossum

Mar 1 '07 #4

P: n/a
An interface is a class (or struct). It contains methods, properties,
indexers or events. It does not provide implementations for any of
its methods.

The advantage of an interface is that any other class (or interface)
can "inherit" (or implement) that interface. It is the C# way to get
something similar to multiple inheritance in C++. Any class that
implements an interface must supply all the members specified in the
interface.
Thanks, rossum, this explains a lot.

But, I need to be more experience before I can understand why an
interface is needed. I never used multiple inheritence before.

Zytan

Mar 1 '07 #5

P: n/a
On Feb 28, 5:13 pm, "Zytan" <zytanlith...@yahoo.comwrote:
An interface is a class (or struct). It contains methods, properties,
indexers or events. It does not provide implementations for any of
its methods.
The advantage of an interface is that any other class (or interface)
can "inherit" (or implement) that interface. It is the C# way to get
something similar to multiple inheritance in C++. Any class that
implements an interface must supply all the members specified in the
interface.

Thanks, rossum, this explains a lot.

But, I need to be more experience before I can understand why an
interface is needed. I never used multiple inheritence before.
Check out these threads:

http://groups.google.com/group/micro...0909d1382f3e68

http://groups.google.com/group/micro...667cc111cc960b

Mar 1 '07 #6

P: n/a
rossum <ro******@coldmail.comwrote:
An interface is a class (or struct). It contains methods, properties,
indexers or events. It does not provide implementations for any of
its methods.
I think it's misleading to say that an interface is a class or a
struct. An interface is a distinct kind of type in itself. It may be
*implemented* by a class or a struct, but in itself, it is neither.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Mar 1 '07 #7

P: n/a
Zytan <zy**********@yahoo.comwrote:
But, I need to be more experience before I can understand why an
interface is needed. I never used multiple inheritence before.
There's much more to interfaces than providing a workaround for the
lack of multiple inheritance. It allows you to use a class knowing only
that it implements the interface. Probably the most commonly used
interface in .NET is IDisposable, which defines the Dispose method.
That means that I could have a method:

void DisposeOfSomething (IDisposable x)
{
x.Dispose();
}

and *anything* implementing IDisposable could be passed to the method.

It's a way of providing polymorphism which is independent of the class
hierarchy (i.e. there's no particular base class needed).

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Mar 1 '07 #8

P: n/a
On Thu, 1 Mar 2007 07:37:45 -0000, Jon Skeet [C# MVP]
<sk***@pobox.comwrote:
>There's much more to interfaces than providing a workaround for the
lack of multiple inheritance. It allows you to use a class knowing only
that it implements the interface.
Well yes, but the same is true if you use a class knowing only that it
implements a given base class...
>It's a way of providing polymorphism which is independent of the class
hierarchy (i.e. there's no particular base class needed).
That's only true because .NET doesn't support multiple inheritance in
the first place. Otherwise you could attach some new base class at an
arbitrary point in any class hierarchy, in the same way as you can now
attach an arbitrary interface. You would no longer consider that
particular base class part of a "hierarchy" either.
--
http://www.kynosarges.de
Mar 1 '07 #9

P: n/a
Chris Nahr <di******@kynosarges.dewrote:
There's much more to interfaces than providing a workaround for the
lack of multiple inheritance. It allows you to use a class knowing only
that it implements the interface.

Well yes, but the same is true if you use a class knowing only that it
implements a given base class...
True.
It's a way of providing polymorphism which is independent of the class
hierarchy (i.e. there's no particular base class needed).

That's only true because .NET doesn't support multiple inheritance in
the first place. Otherwise you could attach some new base class at an
arbitrary point in any class hierarchy, in the same way as you can now
attach an arbitrary interface. You would no longer consider that
particular base class part of a "hierarchy" either.
I would - if a class has two base classes, I'd count both of those as
being in the class hierarchy for that class.

I suppose using interfaces is equivalent to using multiple inheritance
where you can only inherit from one class with any concrete methods. As
I understand it, however, multiple inheritance is usually used to
inherit implementation, not interface. I could be wrong there, of
course.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Mar 1 '07 #10

P: n/a
Check out these threads:
>
http://groups.google.com/group/micro...languages.csha...

http://groups.google.com/group/micro...languages.csha...
Thanks, these help a lot.

You could have implementations that are totally different, say, SQL
data, or flat file (text file) data, or XMl data, and have an
interface that is the same for all of them. And the implementations
of these would use the same interface. The interface *forces* that
all of it is implemented (very good c#) which forces that it is done
correctly. Impressive concept.

Zytan

Mar 1 '07 #11

P: n/a
An interface is a class (or struct). It contains methods, properties,
indexers or events. It does not provide implementations for any of
its methods.

I think it's misleading to say that an interface is a class or a
struct. An interface is a distinct kind of type in itself. It may be
*implemented* by a class or a struct, but in itself, it is neither.
I understand it now. A C# interface (the keyword interface) which
should have the "I" prefix is not the interface portion of a class.
They are both interfaces just as pointers and references are both
references (in plain english). But I understand the distinction now.
IClass means that it is an 'interface' not a 'class'.

Zytan

Mar 1 '07 #12

P: n/a
There's much more to interfaces than providing a workaround for the
lack of multiple inheritance. It allows you to use a class knowing only
that it implements the interface. Probably the most commonly used
interface in .NET is IDisposable, which defines the Dispose method.
That means that I could have a method:

void DisposeOfSomething (IDisposable x)
{
x.Dispose();
}

and *anything* implementing IDisposable could be passed to the method.

It's a way of providing polymorphism which is independent of the class
hierarchy (i.e. there's no particular base class needed).
I have no experience with polymorphism so this is over my head, but I
think I understand. I want two totally different implementations that
show the same interface to the caller. This way, the called need not
care about the internal code, it just uses it, much like, say,
electric motors vs gas motors work under the hood, but have the same
steering wheel and 'gas' pedal to make it move. So, this concept,
which I understand, is basically what polymorphism is, isn't it?

Zytan

Mar 1 '07 #13

P: n/a
On Mar 1, 8:56 am, "Zytan" <zytanlith...@yahoo.comwrote:
Check out these threads:
http://groups.google.com/group/micro...languages.csha...
http://groups.google.com/group/micro...languages.csha...

Thanks, these help a lot.

You could have implementations that are totally different, say, SQL
data, or flat file (text file) data, or XMl data, and have an
interface that is the same for all of them. And the implementations
of these would use the same interface. The interface *forces* that
all of it is implemented (very good c#) which forces that it is done
correctly. Impressive concept.

Zytan
Yes, interface to me is more useful as design mechanism. Look up
Design Patterns.

Quoc Linh

Mar 1 '07 #14

P: n/a
On Mar 1, 10:59 am, "Zytan" <zytanlith...@yahoo.comwrote:
An interface is a class (or struct). It contains methods, properties,
indexers or events. It does not provide implementations for any of
its methods.
I think it's misleading to say that an interface is a class or a
struct. An interface is a distinct kind of type in itself. It may be
*implemented* by a class or a struct, but in itself, it is neither.

I understand it now. A C# interface (the keyword interface) which
should have the "I" prefix is not the interface portion of a class.
They are both interfaces just as pointers and references are both
references (in plain english). But I understand the distinction now.
IClass means that it is an 'interface' not a 'class'.

Zytan
The naming of an interface is irrelevant. You could name it TimBukToo
for all the compiler cares. Prefixing an interface type name with the
letter I is just a best practice. It is not required.
Mar 1 '07 #15

P: n/a
Zytan <zy**********@yahoo.comwrote:
It's a way of providing polymorphism which is independent of the class
hierarchy (i.e. there's no particular base class needed).

I have no experience with polymorphism so this is over my head, but I
think I understand. I want two totally different implementations that
show the same interface to the caller. This way, the called need not
care about the internal code, it just uses it, much like, say,
electric motors vs gas motors work under the hood, but have the same
steering wheel and 'gas' pedal to make it move. So, this concept,
which I understand, is basically what polymorphism is, isn't it?
Yes, that's a pretty reasonable way of looking at it.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Mar 1 '07 #16

P: n/a
PS

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...
rossum <ro******@coldmail.comwrote:
>An interface is a class (or struct). It contains methods, properties,
indexers or events. It does not provide implementations for any of
its methods.

I think it's misleading to say that an interface is a class or a
struct. An interface is a distinct kind of type in itself. It may be
*implemented* by a class or a struct, but in itself, it is neither.
There is a difference between an interface as a .Net construct and interface
as the way in which we interact with an object. You could sat that a class
is it's own interface.

PS
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Mar 1 '07 #17

P: n/a
PS <ec***********@hotmail.comwrote:
I think it's misleading to say that an interface is a class or a
struct. An interface is a distinct kind of type in itself. It may be
*implemented* by a class or a struct, but in itself, it is neither.

There is a difference between an interface as a .Net construct and interface
as the way in which we interact with an object.
Yes - but in the context of someone in a C# group asking what an
interface, I think it's clear what's meant.
You could sat that a class is it's own interface.
Well, I'd say that a class *has* its own public interface (which it
implements), but it *isn't* its own interface.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Mar 1 '07 #18

This discussion thread is closed

Replies have been disabled for this discussion.