Interfaces and Inheritance

[Jay Dee]

Hi all.

I have bean studying the use of Interfaces, and from what I understand
if you create a class that inherits from an interface, that class must
poses a member that represents each member of the derived interface.

Well this all seams sensible because otherwise it would defy the
principles behind inheritance,

I was studying the class “System.Collections.Generic.List<T>”.
This class states that it derives from the interface
“System.Collections.Icollection”
Therefore I would assume that it would possess all the members that
the interface contains.

This is where I become very confused.
“System.Collections.Generic.List<T>” douse not poses the members:

IsSynchronized
SyncRoot

Trying to find an answerer to this I ran the code

<Code>
System.Collections.ICollection i = new
System.Collections.Generic.List<string>();
System.Windows.Forms.MessageBox.Show(i.IsSynchroni zed.ToString());
</Code>

I found that it ran successfully and displayed the value “False”.
This states to me that the class douse in fact poses the member
“IsSynchronized” but fore some reason douse not give you access to it
at design time.

Could anybody please explain this to me?

Thanks Jay Dee

[Jeroen Mostert]

Jay Dee wrote:

I have bean studying the use of Interfaces, and from what I understand
if you create a class that inherits from an interface, that class must
poses a member that represents each member of the derived interface.

Technically, a class does not inherit from an interface, it implements it.
It's useful to make the distinction because the mechanisms are slightly
different.

Well this all seams sensible because otherwise it would defy the
principles behind inheritance,

I was studying the class “System.Collections.Generic.List<T>”.
This class states that it derives from the interface
“System.Collections.Icollection”
Therefore I would assume that it would possess all the members that
the interface contains.

It does.

This is where I become very confused.
“System.Collections.Generic.List<T>” douse not poses the members:

IsSynchronized
SyncRoot

Yes, it does! It implements the interface explicitly. This means you can
only access these members from a reference of type ICollection...

Trying to find an answerer to this I ran the code

<Code>
System.Collections.ICollection i = new
System.Collections.Generic.List<string>();
System.Windows.Forms.MessageBox.Show(i.IsSynchroni zed.ToString());
</Code>

....as you demonstrate here.

Could anybody please explain this to me?

It's called "explicit interface implementation". The MSDN explains it here:
http://msdn.microsoft.com/library/ms173157.aspx

The idea is to use explicit interface implementations when regular clients
are not expected to be interested in the members; only clients accessing the
class through the interface will be.

A clearer example is ICollection.IsReadOnly. For most collections, you do
not want to expose this property because the collection will *always* be
read-only or read-write, as part of its type. In this case it makes sense to
implement the property explicitly, so only consumers of ICollection (who do
not know the specifics of the implementing class) see the property.

--
J.
http://symbolsprose.blogspot.com

[Jon Skeet [C# MVP]]

Jay Dee <fi******@gmail.comwrote:

I have bean studying the use of Interfaces, and from what I understand
if you create a class that inherits from an interface, that class must
poses a member that represents each member of the derived interface.

Well this all seams sensible because otherwise it would defy the
principles behind inheritance,

I was studying the class =3FSystem.Collections.Generic.List<T>=3F.
This class states that it derives from the interface
=3FSystem.Collections.Icollection=3F
Therefore I would assume that it would possess all the members that
the interface contains.

This is where I become very confused.
=3FSystem.Collections.Generic.List<T>=3F douse not poses the members:

Yes it does - but it uses explicit interface implementation to define
them. That means that to use those members, you have to use the
reference exactly as an ICollection, rather than as the concrete type.

Search for C# and "explicit interface implementation" for more details.

--
Jon Skeet - <sk***@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

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

On May 28, 3:02*pm, Jay Dee <[e-mail]:

Hi all.

I have bean studying the use of Interfaces, and from what I understand
if you create a class that inherits from an interface, that class must
poses a member that represents each member of the derived interface.

A class do not inherit from an interface, it does implement it. That
how a class can implement (and behave) like more than one interface
AND inheriting from only one class.

Well this all seams sensible because otherwise it would defy the
principles behind inheritance,

see the above remark

Could anybody please explain this to me?

I think I know the answer, but I would like to see your code first,
Hint, take a look at the difference between explicitely and implicit
interface implementation

[Ben Voigt [C++ MVP]]

Ignacio Machin ( .NET/ C# MVP ) wrote:

On May 28, 3:02 pm, Jay Dee <[e-mail]:

>Hi all.

I have bean studying the use of Interfaces, and from what I
understand if you create a class that inherits from an interface,
that class must poses a member that represents each member of the
derived interface.

A class do not inherit from an interface, it does implement it. That
how a class can implement (and behave) like more than one interface
AND inheriting from only one class.

>Well this all seams sensible because otherwise it would defy the
principles behind inheritance,

see the above remark

I believe the OP was referring to the Liskov Substitution Principle. And in
that sense, classes are as much a subtype of any interfaces as of the base
class(es). They don't, however, inherit any behavior from interfaces. Many
languages have only one means of subtyping, which is usually called
"inheritance". .NET distinguishes between behavioral inheritance
(derivation) and interface inheritance (implementation), however.

>

>Could anybody please explain this to me?

I think I know the answer, but I would like to see your code first,
Hint, take a look at the difference between explicitely and implicit
interface implementation