I see a lot of APIs that use custom collections instead of just using strongly-t
ID: 644350 • Letter: I
Question
I see a lot of APIs that use custom collections instead of just using strongly-typed packaged generics.
For instance, the API will have a Object1Collection instead of just a List<Object1> (or whatever the appropriate generic would be).
When do you know to use one or the other? I understand you'd create a custom collection if you want to extend the capabilities of a pre-shipped generic collection, but what if that's not the case?
Is it prudent to create the custom collection from the beginning, with thoughts that in the future that object might scale up and require further capabilities, and it may be easier to just do that initially? Is that justification enough?
And if you just want to extend functionality, instead of define collection functionality, you would just derive your custom collection from a base generic collection class, otherwise inherit the interface accordingly? Is that typical?
Explanation / Answer
In general, rarely if ever.
You'll occasionally make things that wrap collections and work on collections of things, but you will rarely make a class that is a generic, reusable collection. More often you'll have some class that represents some concept which uses a collection, rather than is a collection.
Why? Because frankly there's only so many data structures in the world, and they've pretty much all been implemented. Maybe you can come up with the next hash table, and if you do, then make a new collection type for it.
If you want to add functionality, either wrap the existing collection or add extension methods to it.
If you see a specific ObjectCollection, I would assume that the API was made during .NET 1.0 (no generics) or for some API that has onerous interoperability requirements put in it.