Inheriting from CollectionBase

[Matthew Roberts]

Howdy Everyone,

I am having trouble understanding the process of creating a type-safe
collection by inheriting from the CollectionBase class. I have done it
plenty of times, but now that I sit down and look at it, I'm wondering
why it behaves the way it does, and also how to improve its
functionality.

First, understand the basic format of a type-safe collection:

Public Class DerivedCollection
Inherits System.Collections.CollectionBase

Public Function Add(ByVal obj As SpecialObject) As SpecialObject
Me.List.Add(obj)
Return obj
End Function

Public Sub Remove(ByVal as SpecialObject)
Me.List.Remove(obj)
End Sub

Default Public ReadOnly Property Item(ByVal Index As Integer) As
SpecialObject
Return CType(Me.List(Index), SpecialObject)
End Property
End Class

Using the above code, how does the compiler know that the Add and
Remove methods correspond to the Add and Remove methods of the IList
interface? Meaning, since there is no Implements statement after any
of the properties or methods, how does consumer code know that my Add
and Remove are the same as standard collection functions Add and
Remove? Isn't it true that a method Implements a function to indicate
to consumer code that it handles some well known methods? Or do
collections not even support this functionality, only ILists.

I have read that the collection base is able to determine where to
find the type-safe enumerator because of the fact that the Item
property is marked Default and ReadOnly. With those keywords, the
compiler knows enough about the collection to have a type-safe
enumerator. Is that close to correct?

Now, let's take the Add and Remove methods out of the collection code
above. If we do this, then we try to use the collection in code, there
is no Add method. How then, is this a real collection? And again, by
me adding my own Add function, how is that Add function logically
related to the standard collection Add function? Is it just because
they share the same name? Or is it that collections don't actually
support Add, Remove, etc., and it is simply up to the developer to
provide that type of functionality?

If you want a custom collection to have other functionality like Sort
or Find, why wouldn't you just inherit from ArrayList?

If you want to code in IndexOf functionality or Insert functionality
like that exposed by the IList of CollectionBase, how will consumer
code know that the functions correspond to the functionality of the
IList? Meaning, if you have a function that expects an IList, then
pass your custom collection to the function, will it work? In the
function, you could access the IndexOf and Insert methods through the
interface, but would the function be able to access the custom IndexOf
and Insert methods, considering there would be no Implements statement
to relate it? Or again, does it just use the name of the method for
the association?

Any information about this subject will be greatly appreciated. I'm
sure I haven't conveyed this idea in the greatest way, so if you need
more information, I can certainly provide it.

Matthew

Please respond to:
mroberts_hm (at) hotmail (dot) com
Or
matthewroberts (at) srcp (dot) com

 

[CJ Taylor]

Hey Matt,

hopefully this can help.

Howdy Everyone,

I am having trouble understanding the process of creating a type-safe
collection by inheriting from the CollectionBase class. I have done it
plenty of times, but now that I sit down and look at it, I'm wondering
why it behaves the way it does, and also how to improve its
functionality.

First, understand the basic format of a type-safe collection:

Public Class DerivedCollection
Inherits System.Collections.CollectionBase

Public Function Add(ByVal obj As SpecialObject) As SpecialObject
Me.List.Add(obj)
Return obj
End Function

Public Sub Remove(ByVal as SpecialObject)
Me.List.Remove(obj)
End Sub

Default Public ReadOnly Property Item(ByVal Index As Integer) As
SpecialObject
Return CType(Me.List(Index), SpecialObject)
End Property
End Class

Using the above code, how does the compiler know that the Add and
Remove methods correspond to the Add and Remove methods of the IList
interface? Meaning, since there is no Implements statement after any
of the properties or methods, how does consumer code know that my Add
and Remove are the same as standard collection functions Add and
Remove? Isn't it true that a method Implements a function to indicate
to consumer code that it handles some well known methods? Or do
collections not even support this functionality, only ILists.

Techincally, your not implementing IList within your inherited class. So
the question of "how does it know?" is correct.

HOWEVER

CollectionBase does implemnet IList, ICollection, and IEnumerable. So by
rules of inheritance IList works. Now your Add is not an implementation of
IList, so if you had a variable of IList and it referenced your typed
collection you would actually be calling the Add on the parent collection
(collectionbase) and not the Add you have (because the relationship isn't
defined).

I have read that the collection base is able to determine where to
find the type-safe enumerator because of the fact that the Item
property is marked Default and ReadOnly. With those keywords, the
compiler knows enough about the collection to have a type-safe
enumerator. Is that close to correct?

I don't know about that. That would be defining Item as a keyword in a
class, that just doesn't sound like a good idea. =)

Now, let's take the Add and Remove methods out of the collection code
above. If we do this, then we try to use the collection in code, there
is no Add method. How then, is this a real collection? And again, by
me adding my own Add function, how is that Add function logically
related to the standard collection Add function? Is it just because
they share the same name? Or is it that collections don't actually
support Add, Remove, etc., and it is simply up to the developer to
provide that type of functionality?

If you want a custom collection to have other functionality like Sort
or Find, why wouldn't you just inherit from ArrayList?

The joys of inheritance. =) It's understanding direct inheritance vs.
implementation inhertiance. Direct you can only derive from a single class
(which can inherit from...... right.. you get it). Implementation
inheritance can derive from many classes. Except, Implmentation doesn't
actually perform any logical functions, the class that implements it does.

If you want to code in IndexOf functionality or Insert functionality
like that exposed by the IList of CollectionBase, how will consumer
code know that the functions correspond to the functionality of the
IList? Meaning, if you have a function that expects an IList, then
pass your custom collection to the function, will it work? In the
function, you could access the IndexOf and Insert methods through the
interface, but would the function be able to access the custom IndexOf
and Insert methods, considering there would be no Implements statement
to relate it? Or again, does it just use the name of the method for
the association?

No doesn't use the name of the method. It could be that its looking at it
as an overrides, and thats why its working, or your not doing anything
specific enough with your collection that it matters. Or better yet,
because of inheritance (I believe the List property is a protected property)
its working...

Hope this helped, but please feel free to ask more questions. I kinda tried
to cram about 30 pages of ideas into a few paragraphs. =)

-CJ