List<BusinessObject> or BusinessObjectCollection?

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 generally only derive my own collection classes if I need to "add value". Like, if the collection itself needed to have some "metadata" properties tagging along with it.

Answer 2

I've been going back and forth on 2 options:

public class BusinessObjectCollection : List<BusinessObject> {}

or methods that just do the following:

public IEnumerable<BusinessObject> GetBusinessObjects();

The benefits of the first approach is that you can change the underlying data store without having to mess with method signatures. Unfortunately if you inherit from a collection type that removes a method from the previous implementation, then you'll have to deal with those situations throughout your code.

Answer 3

I do the exact same thing as you Jonathan... just inherit from List<T>. You get the best of both worlds. But I generally only do it when there is some value to add, like adding a LoadAll() method or whatever.

Answer 4

6 of 1, half dozen of another

Either way its the same thing. I only do it when I have reason to add custom code into the BusinessObjectCollection.

With out it having load methods return a list allows me to write more code in a common generic class and have it just work. Such as a Load method.

Answer 5

I prefer just to use List<BusinessObject>. Typedefing it just adds unnecessary boilerplate to the code. List<BusinessObject> is a specific type, it's not just any List object, so it's still strongly typed.

More importantly, declaring something List<BusinessObject> makes it easier for everyone reading the code to tell what types they are dealing with, they don't have to search through to figure out what a BusinessObjectCollection is and then remember that it's just a list. By typedefing, you'll have to require a consistent (re)naming convention that everyone has to follow in order for it to make sense.

Answer 6

You should probably avoid creating your own collection for that purpose. It's pretty common to want to change the type of data structure a few times during refactorings or when adding new features. With your approach, you would wind up with a separate class for BusinessObjectList, BusinessObjectDictionary, BusinessObjectTree, etc.

I don't really see any value in creating this class just because the classname is more readable. Yeah, the angle bracket syntax is kind of ugly, but it's standard in C++, C# and Java, so even if you don't write code that uses it you're going to run into it all the time.

Answer 7

It's recommended that in public API's not to use List<T>, but to use Collection<T>

If you are inheriting from it though, you should be fine, afaik.

Answer 8

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.

Answer 9

I use generic lists for almost all scenarios. The only time that I would consider using a derived collection anymore is if I add collection specific members. However, the advent of LINQ has lessened the need for even that.

Answer 10

this is the way:

return arrays, accept IEnumerable<T>

=)

Answer 11

As someone else pointed out, it is recommended not to expose List publicly, and FxCop will whinge if you do so. This includes inheriting from List as in:

public MyTypeCollection : List<MyType>

In most cases public APIs will expose IList (or ICollection or IEnumerable) as appropriate.

In cases where you want your own custom collection, you can keep FxCop quiet by inheriting from Collection instead of List.

Answer 12

If you choose to create your own collection class you should check out the types in System.Collections.ObjectModel Namespace.

The namespace defines base classes thare are ment to make it easier for implementers to create a custom collections.

Answer 13

I tend to do it with my own collection if I want to shield the access to the actual list. When you are writing business objects, chance is that you need a hook to know if your object is being added/removed, in such sense I think BOCollection is better idea. Of coz if that is not required, List is more lightweight. Also you might want to check using IList to provide additional abstraction interface if you need some kind of proxying (e.g. a fake collection triggers lazy load from database)

But... why not consider Castle ActiveRecord or any other mature ORM framework? :)

Answer 14

At the most of the time I simply go with the List way, as it gives me all the functionality I need at the 90% of the time, and when something 'extra' is needed, I inherit from it, and code that extra bit.

Answer 15

I would do this:

using BusinessObjectCollection = List<BusinessObject>;

This just creates an alias rather than a completely new type. I prefer it to using List<BusinessObject> directly because it leaves me free to change the underlying structure of the collection at some point in the future without changing code that uses it (as long as I provide the same properties and methods).

Answer 16

try out this:

System.Collections.ObjectModel.Collection<BusinessObject>

it makes unnecessary to implement basic method like CollectionBase do

Answer 17

You can use both. For laziness - I mean productivity - List is a very useful class, it's also "comprehensive" and frankly full of YANGNI members. Coupled with the sensible argument / recommendation put forward by the MSDN article already linked about exposing List as a public member, I prefer the "third" way:

Personally I use the decorator pattern to expose only what I need from List i.e:

public OrderItemCollection : IEnumerable<OrderItem> 
{
    private readonly List<OrderItem> _orderItems = new List<OrderItem>();

    void Add(OrderItem item)
    {
         _orderItems.Add(item)
    }

    //implement only the list members, which are required from your domain. 
    //ie. sum items, calculate weight etc...

    private IEnumerator<string> Enumerator() {
        return _orderItems.GetEnumerator();
    }

    public IEnumerator<string> GetEnumerator() {
        return Enumerator();
    }    
}

Further still I'd probably abstract OrderItemCollection into IOrderItemCollection so I can swap my implementation of IOrderItemCollection over in the future in (I may prefer to use a different inner enumerable object such as Collection or more likley for perf use a Key Value Pair collection or Set.

Answer 18

Use the type List<BusinessObject> where you have to declare a list of them. However, where you return a list of BusinessObject, consider returning IEnumerable<T>, IList<T> or ReadOnlyCollection<T> - i.e. return the weakest possible contract that satisfies the client.

Where you want to "add custom code" to a list, code extension methods on the list type. Again, attach these methods to the weakest possible contract, e.g.

public static int SomeCount(this IEnumerable<BusinessObject> someList)

Of course, you can't and shouldn't add state with extension methods, so if you need to add a new property and a field behind it, use a subclass or better, a wrapper class to store this.