Interfaces and Inheritance

J

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.IsSynchronized.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
 
J

Jeroen Mostert

Jay said:
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.IsSynchronized.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

Jon Skeet [C# MVP]

Jay Dee said:
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.
 
I

Ignacio Machin ( .NET/ C# MVP )

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
 
B

Ben Voigt [C++ MVP]

Ignacio said:
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.


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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top