Our main application at work was primarily built using .Net 1.1.  That being said, most of the collection objects inherit from a base class that gives support for things like adding to, removing from, and enumerating through the collection.  We have since migrated the application to .Net 2.0 but there has been little incentive to go back and update these collections to use the support for generics that was added as part of the .Net 2.0 framework.

 

Recently I took on the role of lead developer for a smaller, internal project that will live independently from any of our other apps.  The fact that this app will not use any of the business objects or the same database meant that I was free to utilize whatever technology I thought best suited for the project.  Eventually, I settled on developing the application in the newly released .Net 3.5 framework using C# 3.0 mainly due to the fact that I was anxious to start using Linq (I know, probably not the most solid reason for choosing a platform, but it is a reason, and that’s really all I needed).  When I started building up my business object layer, I eventually came across the need for collections.  The base class that was ported over from .Net 1.1 would have been more than adequate, but I knew that if I wanted to use Linq, I would have to inherit from something that implemented the IEnumerable interface.  After looking around the web and playing around with a few different methods, I eventually decided that the easiest way to build up the collection would be to inherit from the List<T> generic class (where ‘T’ is the type of object that will live in the collection).

 

Here is an example using a widget object to populate a collection of widget:

 

The widget object:

public class Widget
{
    /// <summary>
    /// The Widget ID
    /// </summary>
    public int WidgetID { get; set; } </p>

    </font>/// <summary>
    /// The Widget Name
    /// </summary>
    public string WidgetName { get; set; } </p>

    </font>/// <summary>
    /// The default public constructor.
    /// </summary>
    /// <param name="ID">The widget ID</param>
    /// <param name="Name">The widget Name</param>
    public Widget(int ID, int Name)
    {
        WidgetID = ID;
        WidgetName = Name;
    }
} </div>

 

The widget collection:

public class WidgetCollection : List<Widget>
{
    /// <summary>
    /// The default public constructor.
    /// </summary>
    public WidgetCollection()
    {
        Reload();
    } </p>

    </font>/// <summary>
    /// Load the collection.  This would normally be done from the database.
    /// </summary>
    private void Load()
    {
        this.Add(new Widget(1, "Widget1"));
        this.Add(new Widget(2, "Widget2"));
    } </p>

    </font>/// <summary>
    /// Clear out the collection and reload it.
    /// </summary>
    public void Reload()
    {
        this.Clear();
        Load();
    }
} </div>

 

This gives me the ability to then bind dropdowns within the program as well as the ability to manipulate the collection using Linq (which is what I was after all along).

 

So, how about you?  Is inheriting from List<T> a pretty standard way of building up collections, or have I stumbled upon one of those programming faux pas that more experienced developers know to avoid?