Confused about interfaces

Quercus

Well-known member
Joined
Oct 21, 2002
Messages
53
Location
Maryland
As a spinoff from my other thread on overriding non-virtual methods, Ive been doing some work with interfaces and Im 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:

Code:
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 ILists 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:

Code:
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.
 
The [mshelp=ms-help://MS.MSDNQTR.2003FEB.1033/cpref/html/frlrfSystemCollectionsCollectionBaseClassTopic.htm]CollectionBase class[/mshelp] is declared thusly:
C#:
public abstract class CollectionBase : IList, ICollection, IEnumerable

As you can see, CollectionBase already implements IList and
overrides the Add method for you. Youre just trying too hard. :)
 
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 dont understand why the compiler didnt enforce the IList interface.
 
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 dont have to.

Ive also had trouble overloading methods like you said, so I
unfortunately cannot answer the second part of your question.
 
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 doesnt expose it. If I inherit CollectionBase, but dont implement an Add of my own, my class wont have an Add mehtod. It doesnt inherit it from CollectionBase.

But you are syaing that even so, CollectionBase has implemented Add in some form or other, even if I cant use it. And therefore, I can compile even if I havent implemented the IList interface myself. Yes?
 
If CollectionBase implements the IList interface, but the IList implementation is private, then I dont see the point. I dont 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 doesnt enforce the interface. This picture is getting clearer, but its not crystal yet.
 
Okay. I now understand how CollectionBase has explicitly implemented IList, and why I can use CollectionBase without being bound myself to IList. However, I dont 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.
 
Back
Top