c# - .NET Collection Naming Convention

Question

My colleague and I have been having a discussion about what Collections should be called.

For example:

Class Product - Collection - Class Products

or

Class Product - Collection - Class ProductCollection

I've had a look around to see if I can see any guidelines or reasons for using one or the other but nothing seems to spring out. The framework seems to use both variants for example. The argument I can see is that a class that has a collection of products variable should be called Products but it should be of type ProductCollection.

Which is correct if any?

In the same vane is there a standard for the naming of return variable for a function. e.g. retVal?

We mainly code in C#, although I'm not sure that affects my question.

Answer 1

I would say that with generics there should rarely ever be a reason to create a custom collection type. But if you must I would say that ProductCollection would best fit the naming conventions of the framework.

Still, consider using a List<Product> or Collection<Product> or better yet IList<Product> or ICollection<Product>.

Edit: This is in response to MrEdmundo's comments below.

In your case you have two choices. The most obvious choice would be to use inheritance like this:

class Ball { }

class BallCollection : List<Ball>
{
    public String Color { get; set; }
    public String Material { get; set; }
}

I say obvious because it seems like the best idea at first glance but after a bit of thought it becomes clear that this is not the best choice. What if you or Microsoft creates a new SuperAwesomeList<T> and you want to use that to improve the performance of your BallCollection class? It would be difficult because you are tied to the List<T> class through inheritance and changing the base class would potentially break any code that uses BallCollection as a List<T>.

So what is the better solution? I would recommend that in this case you would be better off to favor composition over inheritance. So what would a composition-based solution look like?

class Ball { }

class BallCollection
{
    public String Color { get; set; }
    public String Material { get; set; }
    public IList<Ball> Balls { get; set; }
}

Notice that I have declared the Balls property to be of type IList<T>. This means that you are free to implement the property using whatever type you wish as long as that type implements IList<T>. This means that you can freely use a SuperAwesomeList<T> at any point which makes this type significantly more scalable and much less painful to maintain.