Generics and object collections

In VS2003, since we don’t have generics, we have lots of strongly-typed collections.
For example, there’s the LinkCollection class, which holds objects of type Link.

Now that we have generics, we could replace such collections with:


(well, actually, we couldn’t replace them, as that would break existing code, but
we could do that for new collections). That seems like a simple solution, but it isn’t
optimal, for a couple of reasons:

  1. Sometimes the type in the collection isn’t sufficiently distinctive, especially if
    it’s a built-in type. You’d like to see something like EmployeeIDCollection rather
    than List<int>
  2. It’s often useful to add additional functionality to the collection beyond what you
    get from the built-in collection class.

The better solution is to define your own collection class. Nicely, you can base it
off of the collection class:

class EmployeeIDCollection: List<int>

The design guideline is not to expose collection classes, but rather to expose custom
collection classes (I really need a better name for those) instead.




Comments (9)

  1. Should I understand this post as if you don’t agree with <a href="">this blog post by Martin Fowler</a>?

    Best Regards,

  2. ::well, actually, we couldn’t replace them, as that would break existing code

    And this is where I just turn around and cry.

    So, you leave all the buggy (yes, they DO have bugs) 1.0/1.1 generic lists in your code?

    This is pathetic. I want a clean workable .NET 2.0 DOnt start polluting the framework yet. You ahve a chance here. BREAK THE CODE, give me a better and less buggy framework.

  3. Val Savvateev says:

    Eric, you’re making a good point here. However I think it’s realization is calling for having a typedef-kind of statement. I understand the reasons why typedef/define constructs are dislikable, but what about just having a shortened version of class declaration syntax where "{}" will not be required, i.e.:

    class EmployeeIDCollection: List<int>;

    instead of

    class EmployeeIDCollection: List<int>{}

    I just foresee myself creating alot of those "custom" classes that wont really add any new functionality to the base classes.

  4. Eric Gunnerson says:


    I his blog entry, Martin says in relation to custom-typed collections

    "On the whole, however, it isn’t worth the trouble"

    If you have to write them by hand, or use some generator program, I agree with him. But if you don’t, then it’s fairly low effort to have a strongly-typed collection, and I think it has real advantages over a simple List<Employee>.

    This is specifically for the library design case. I’m not sure yet how I feel about what you should do with collections inside a component, as I haven’t thought about it a lot. My initial guess is that I will tend to use something like List<Employee> because it’s simpler.

    Martin also makes an interesting point about encapsulated collections, though I’m not sure how to reconcile his advice to use one vs. his early comment about just using a parameterized collection. Anyway, I think there are times that you’d want to have encapsulation, but there are also times where you want your classes to be more promiscuous, so to speak.

  5. Eric Gunnerson says:


    I sympathize with your comments – we all agree that the frameworks would be much nicer if we had had generics in the first version, and we wouldn’t have the ugliness of having multiple versions of collection classes.

    But I don’t think we can make changes that are likely to break existing code, and if we tried to back-patch generic lists into places where the user used a non-generic list, I think we would break a fair bit of code. I don’t think it’s unreasonable for users to want to recompile and not have this happen.

    If you want to get rid of the non-generic classes, you should be able to change your using statement and then fix things up by hand. It’s possible you’ll need to revisit some code, especially if you store value types in collections, as you don’t have a null value option in a generic collection that holds a value type.

  6. Doug McClean says:

    I’m late to this thread, but I’m bored so I’m perusing the archives.

    Would a possible solution to the break/don’t break question be to keep the existing System.Collections types defined as they are but move them out of mscorlib? Then if you want the old ones you can add a reference and be on your way, the new version stays consistent, and we don’t need a (crufty) System.Collections.Generic namespace. I’m sure there’s a problem with this idea (maybe related to the GAC and versioning policy?).

    Will System.Collections.ArrayList at least be marked as [Obsolete] in version 2? And a related question, what is the CLS policy with respect to generics?