Question

I have a business object collection (representing data from the database) that inherits from Collection and has a static method that calls a stored proc and then populates its properties with the data returned.

My question is; is it wrong to inherit from Collection as it doesnt really extend the class? or would it be better to not inherit from anything but instead maintain a private variable that is of type Collection?

Answer 1

It is hard to give an answer to this without seeing a lot more detail about what you are trying to do. However, I would not normally inherit from Collection as it does not really give enough virtual methods to override. This can make altering the behaviour of your class a little tricky in the future.

The trouble with inheritance is that if you use it you will be stuck with the Collection base class’s behaviour forever more, or face a complex refactoring. For example, you may want to add filtering, searching and sorting operations at which point you will need to switch to List from Collection. You may even want to do data binding where you will need a BindingList instead of a Collection.

A different plan would be to inherit from ICollection or better still IList<T> and then delegate to a private Collection member. This gives you maximum control and allows you to alter the internal representation of your class without affecting the public interface. The trouble with this is that it takes longer to develop you classes.

Therefore, what you are facing is a trade off between faster development and future flexibility, and as I said at the start it is a bit difficult to judge which way to go from the information given in the original post.

PS: To make an IList<T> implementation read-only, simply return true from IsReadOnly and then throw a NotSupportedException from all the methods that alter the list.