Confused about interfaces

[Quercus]

As a spinoff from my other thread on overriding non-virtual methods, I've been doing some work with interfaces and I'm confused about interfaces in C#.

 

Specifically, I am creating a collection class, MyCollection, that inherits Collections.CollectionBase and IList. MyCollection will store only objects of type MyItem. Therefore, I have:

 

public class MyCollection : Collections.CollectionBase, IList
{
 // stuff
 public int Add(MyItem item)
 {
   return List.Add(item);
 }
 // more stuff
}

 

And it works just fine. What I am confusted about is that this class implements the IList interface which defines, among other methods:

 

public int Add(object item);

 

Because the signature of my Add method is not the same as the signature of IList's Add method, (not to mention the fact that I have not yet bothered to implement some of the other IList methods) I would expect to get compile errors because I have not faithfully implemented the IList interface.

 

For example, if I define:

 

public interface IMine
{
 // Method
 int Add(object item);

 // Property
 int MyValue
 {
   get;
 }
}

 

And then modify my collection class to implement IMine:

 

public class MyCollection : Collections.CollectionBase, IList, IMine

 

And change nothing else in my class, I will get compile errors becase I did not implement either the Add(object item) or the MyValue members.

 

So why is the IList interface different from the IMine interface? Why does the compiler enforce IMine, but give me flexability in IList? I hope someone can explain this to me.

 

Thanks.

[Bucky]

The [mshelp=ms-help://MS.MSDNQTR.2003FEB.1033/cpref/html/frlrfSystemCollectionsCollectionBaseClassTopic.htm]CollectionBase class[/mshelp] is declared thusly:

public abstract class CollectionBase : IList, ICollection, IEnumerable

 

As you can see, CollectionBase already implements IList and

overrides the Add method for you. You're just trying too hard. :)

[Quercus]

CollectionBase my implement the IList (and other) interfaces, but I do not believe that it has implemented the Add or some other key members. The documentation for CollectionBase specifically says that these methods are up to the programmer. Even given that CollectionBase does implement IList, then my original question still stands: why am I allowed to inherit CollectionBase (and hence, IList) without faithfully implementing the interface?

 

Even if CollectionBase had implemented an Add method (see my trials and tribulations in the thread Override non-virtual regarding the ObjectCollection class) then my implementation of Add(MyItem item) would overload the Add(object item) method already implemented by the CollectionBase class. But this is not the case. The user of the MyCollection class only has the one Add method.

 

I still don't understand why the compiler didn't enforce the IList interface.

[Bucky]

Just because a class is declared abstract does not mean that

every method of the class must be overriden; code can still be

written inside methods and property accessors of abstract

classes. The CollectionBase faithfully implements the Add method

of the IList interface so you don't have to.

 

I've also had trouble overloading methods like you said, so I

unfortunately cannot answer the second part of your question.

[Quercus]

So if I understand you correctly, you are saying that the CollectionBase class, declared as Abstract, does in fact implement the Add method, even though it doesn't expose it. If I inherit CollectionBase, but don't implement an Add of my own, my class won't have an Add mehtod. It doesn't inherit it from CollectionBase.

 

But you are syaing that even so, CollectionBase has implemented Add in some form or other, even if I can't use it. And therefore, I can compile even if I haven't implemented the IList interface myself. Yes?

[PlausiblyDamp]

Ignore this - I was wrong :) Edited February 5, 2004 by PlausiblyDamp

[Quercus]

If CollectionBase implements the IList interface, but the IList implementation is private, then I don't see the point. I don't see what I get out of the IList implementation within CollectionBase - I still have to do all the work myself. Furthermore, even if I explicitly call on the IList:

 

public class MyCollection : Collections.CollectionBase, IList

 

The compiler still doesn't enforce the interface. This picture is getting clearer, but it's not crystal yet.

[PlausiblyDamp]

Firstly ignore what I said earlier - CollectionBase isn't abstract. However I did remember something and I've had time to dig something up.

 

Firstly This Link explains a bit and may solve your original problem as well ;)

 

If that made sense then Here's the MSDN description

 

and another Little tutorial

[Quercus]

Okay. I now understand how CollectionBase has explicitly implemented IList, and why I can use CollectionBase without being bound myself to IList. However, I don't understand *why* CollectionBase has implemented IList - I presume for its own internal requirements.

 

Nevertheless, this give me what I need to move forward with my work. Thanks.