Question

Prior to C# generics, everyone would code collections for their business objects by creating a collection base that implemented IEnumerable

IE:

public class CollectionBase : IEnumerable 

and then would derive their Business Object collections from that.

public class BusinessObjectCollection : CollectionBase 

Now with the generic list class, does anyone just use that instead? I’ve found that I use a compromise of the two techniques:

public class BusinessObjectCollection : List<BusinessObject> 

I do this because I like to have strongly typed names instead of just passing Lists around.

What is your approach?

Answer 1

I am generally in the camp of just using a List directly, unless for some reason I need to encapsulate the data structure and provide a limited subset of its functionality. This is mainly because if I don’t have a specific need for encapsulation then doing it is just a waste of time.

However, with the aggregate initializes feature in C# 3.0, there are some new situations where I would advocate using customized collection classes.

Basically, C# 3.0 allows any class that implements IEnumerable and has an Add method to use the new aggregate initializer syntax. For example, because Dictionary defines a method Add(K key, V value) it is possible to initialize a dictionary using this syntax:

var d = new Dictionary<string, int> {     {'hello', 0},     {'the answer to life the universe and everything is:', 42} }; 

The great thing about the feature is that it works for add methods with any number of arguments. For example, given this collection:

class c1 : IEnumerable {     void Add(int x1, int x2, int x3)     {         //...     }      //... } 

it would be possible to initialize it like so:

var x = new c1 {     {1,2,3},     {4,5,6} } 

This can be really useful if you need to create static tables of complex objects. For example, if you were just using List<Customer> and you wanted to create a static list of customer objects you would have to create it like so:

var x = new List<Customer> {     new Customer('Scott Wisniewski', '555-555-5555', 'Seattle', 'WA'),     new Customer('John Doe', '555-555-1234', 'Los Angeles', 'CA'),     new Customer('Michael Scott', '555-555-8769', 'Scranton PA'),     new Customer('Ali G', '', 'Staines', 'UK') } 

However, if you use a customized collection, like this one:

class CustomerList  : List<Customer> {     public void Add(string name, string phoneNumber, string city, string stateOrCountry)     {         Add(new Customer(name, phoneNumber, city, stateOrCounter));     } } 

You could then initialize the collection using this syntax:

var customers = new CustomerList {     {'Scott Wisniewski', '555-555-5555', 'Seattle', 'WA'},     {'John Doe', '555-555-1234', 'Los Angeles', 'CA'},     {'Michael Scott', '555-555-8769', 'Scranton PA'},     {'Ali G', '', 'Staines', 'UK'} } 

This has the advantage of being both easier to type and easier to read because their is no need to retype the element type name for each element. The advantage can be particularly strong if the element type is long or complex.

That being said, this is only useful if you need static collections of data defined in your app. Some types of apps, like compilers, use them all the time. Others, like typical database apps don’t because they load all their data from a database.

My advice would be that if you either need to define a static collection of objects, or need to encapsulate away the collection interface, then create a custom collection class. Otherwise I would just use List<T> directly.