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?

  • Not all APIs have access to .NET style generics. In order to accommodate other languages, some method has to be built to allow multiple objects to be passed to the API. Were you referring to .NET APIs when you said "I see a lot of APIs that use custom collections instead of just using strongly-typed packaged generics"? – Adam Zuckerman Apr 2 '14 at 0:30
  • Adam, thank you for your reply. Yes, these are almost all .NET APIs that I'm referring to. Maybe "a lot" is a big of an exaggeration, just looking to see the reasoning behind it all. To be honest... custom collections do look a little bit "cleaner". – user3175663 Apr 2 '14 at 0:51
  • How does a property of CustomCollection cc look any cleaner than List<myType> cc? – Adam Zuckerman Apr 2 '14 at 0:54
  • 1
    Look cleaner? Well, but I don't know what exactly this FooCollection is lest I look up how it is implemented. If I see a List<Foo>, I know straight away what it is. If all FooCollection does is provide a "clean" alias for a well-known native .NET type, I say it's a bad move – Konrad Morawski Apr 2 '14 at 6:45

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.


Custom collections don't really make sense for general programming. Thats why List<T> exists. But they sure make lots of sense in domain modelling. For example, you would like to have special behavior that happens when you add a new item into a collection. The best way to do it is to create custom collection class, derive from Collection<T> and overload the Add method.

Also, there is question of what actually is a "custom collection". Is having Add method and implementing IEnumerable<T> enough or does the class have to derive from Collection<T>?

So as Telastyn said. You are generally not going to implement new collections in a way of creating new ways of storing data. That problem has long been solved. But you sure can (and should) create custom collections as a way of expressing domain behavior on those collections.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.