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?
If it's OK for your business object to provide usual collection methods to the world, then it's quite OK to inherit from Collection<T>. And as I guess, in fact you add something to it - you specify T.
Udate:
According to author's comments, publishing of all collection methods would make object editable which is not acceptable. So instead of inheriting he would make private field and make the class enumerable.
Actually, the most "pure" approach is not to add anything when you inherit an object. Hardly anyone tries to be that pure, but that is considered more pure. The idea is you might override certain methods to "fill in the blanks" about how your object behaves, but that you would not add any non-private members.
I don't advocate trying to be that pure. The point is, what you're doing is not "impure" in any way. (Note: I'm not at all using "pure" and "impure" in the sense they're used with functional languages. Simply in the general sense of the dictionary definitions of the words).
Yes it is wrong. You should just have an object that does the bringing back of the Collection. Also, don't make the method static unless there is a compelling need to. There is nothing wrong with new Blah().foo(). Any decent JIT will inline away the object creation.
Also, I think extending Collection is wrong in 99% of cases :) Usually, when people extend Collection what they really should be doing is just composing a List and exposing only what clients really need or just using a plain List.
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.