What's advantage of CollectionBase?

[Samuel R. Neff]

What's the advantage of inheriting from CollectionBase as opposed to
just implementing IList? It seems that it saves you from having to
implement a few properties (Clear, CopyTo, Count, GetEnumerator, and
RemoveAt) but the way it implements all the other things you need to
override seems overkill and counters the advantage of having an
extensible base class.

For example, the documentation example implementation of Remove:

Public Class Int16Collection
Inherits CollectionBase

...

Public Sub Remove(value As Int16)
List.Remove(value)
End Sub 'Remove

...
End Class

Resolves to this call sequence:

Int16Collection.Remove ->
CollectionBase.get_List ->
((IList)CollectionBase).Remove ->
CollectionBase.InnerList.Remove

Whereas if one implemented IList directly, without collection base,
the equivalent call sequence would just be

Int16Collection.Remove ->
Int16Collection.InnerList.Remove

And this comparison is typical for all other operations as well.

So what's the advantage of using CollectionBase? Does everyone use
it? What's downside to just implementing IList?

Of course the question becomes moot when 2005 is out with Generics,
but the question is pertinent now...

Thanks,

Sam

[Jay B. Harlow [MVP - Outlook]]

Samuel,

So what's the advantage of using CollectionBase? Avoiding duplication of code, as you stated: Clear, CopyTo, Count,
GetEnumerator, and RemoveAt are all publicly implemented for you. Plus you
get the rest of the IList members privately implemented for you (about 11
more functions).

All you need to add to your derived class is the specific type safe methods.
Alternatively you can override the On* methods to ensure that the IList
interface itself remains type safe.
Public Sub Remove(value As Int16)
List.Remove(value)
End Sub 'Remove You do know the difference & importance of using CollectionBase.List &
CollectionBase.InnerList are?

Normally I use CollectionBase.InnerList as it represents the contained
ArrayList itself. Using CollectionBase.List ensures the On* methods to be
called, I use CollectionBase.List when I want the public method to also call
the On* method, for example when my derived CollectionBase class
encapsulates a HashTable also. For example:

Public Class PersonCollection
Inherits CollectionBase

Private Readonly m_table As New HashTable

Public Sub Remove(value As Person)
List.Remove(value)
End Sub 'Remove

Protected Overrides Sub OnRemoveComplete(ByVal index As Integer, _
ByVal value As Object)
Dim person As Person = DirectCast(value, Person)
m_table.Remove(person.Name)
End Sub

...

End Sub

When a Person is removed from the collection, via either Remove or
IList.Remove it will be removed from the contained HashTable also.

NOTE: PersonCollection is an ordered list before its a Dictionary, hence it
inherits from CollectionBase instead of DictionaryBase. If it inherited from
DictionaryBase it would contain an ArrayList to maintain the order...
Alternatively PersonCollection could inherit from
NameObjectCollectionBase...
Does everyone useit? I normally use CollectionBase, or I have my own variation of it.
What's downside to just implementing IList? If you are defining a number of lists, the downside is you need to duplicate
the implementation of IList in a number of lists.

Duplication of code is "bad" in a number of OO circles.
Of course the question becomes moot when 2005 is out with Generics,
but the question is pertinent now... Last I read Generics are not CLS compliant, using CollectionBase for public
CLS compliant classes remains pertinent in 2005!

Hope this helps
Jay

"Samuel R. Neff" <bl****@newsgroup.nospam> wrote in message
news:9e********************************@4ax.com...
What's the advantage of inheriting from CollectionBase as opposed to
just implementing IList? It seems that it saves you from having to
implement a few properties (Clear, CopyTo, Count, GetEnumerator, and
RemoveAt) but the way it implements all the other things you need to
override seems overkill and counters the advantage of having an
extensible base class.

For example, the documentation example implementation of Remove:

Public Class Int16Collection
Inherits CollectionBase

...

Public Sub Remove(value As Int16)
List.Remove(value)
End Sub 'Remove

...
End Class

Resolves to this call sequence:

Int16Collection.Remove ->
CollectionBase.get_List ->
((IList)CollectionBase).Remove ->
CollectionBase.InnerList.Remove

Whereas if one implemented IList directly, without collection base,
the equivalent call sequence would just be

Int16Collection.Remove ->
Int16Collection.InnerList.Remove

And this comparison is typical for all other operations as well.

So what's the advantage of using CollectionBase? Does everyone use
it? What's downside to just implementing IList?

Of course the question becomes moot when 2005 is out with Generics,
but the question is pertinent now...

Thanks,

Sam

[Robby]

The main advantage of inheriting CollectionBase is the creation of strongly
typed collections. Do you this your class needs to inherit ColloectionBase
and then override its methods and properties that take or return Object to
replace it with your object.

However, this is quite time consuming and requires you to write a new class
for every strongly typed collection. VB.Net 2005 solves this by further
moving VB into the Object Oriented Programming by adding Generic, or as they
are called in C++, Template classes.

Robby

"Samuel R. Neff" <bl****@newsgroup.nospam> wrote in message
news:9e********************************@4ax.com...

What's the advantage of inheriting from CollectionBase as opposed to
just implementing IList? It seems that it saves you from having to
implement a few properties (Clear, CopyTo, Count, GetEnumerator, and
RemoveAt) but the way it implements all the other things you need to
override seems overkill and counters the advantage of having an
extensible base class.

For example, the documentation example implementation of Remove:

Public Class Int16Collection
Inherits CollectionBase

...

Public Sub Remove(value As Int16)
List.Remove(value)
End Sub 'Remove

...
End Class

Resolves to this call sequence:

Int16Collection.Remove ->
CollectionBase.get_List ->
((IList)CollectionBase).Remove ->
CollectionBase.InnerList.Remove

Whereas if one implemented IList directly, without collection base,
the equivalent call sequence would just be

Int16Collection.Remove ->
Int16Collection.InnerList.Remove

And this comparison is typical for all other operations as well.

So what's the advantage of using CollectionBase? Does everyone use
it? What's downside to just implementing IList?

Of course the question becomes moot when 2005 is out with Generics,
but the question is pertinent now...

Thanks,

Sam