"Base abstract generic class is a bad choice in most situations." Why? (Or Why not)

Question

I have just seen on the comment to a blog post:

Base abstract generic class is a bad choice in most situations

Is this true, if not why?

What insight(s) leads to this statement?

Answer 1

I agree, because anything that inherits an abstract generic class will not be polymorphic with the base class. That is, if you have

abstract class myBase<T>

then you create

class myThing: myBase<thing> class myOtherThing: myBase<otherThing> 

you can't create methods that work against myThing and myOtherThing since they do not share an ancestor. There's no point in the base class being abstract, really, it might as well just be a class.

But if you have a base class

abstract class myBase class myBase<T>: myBase 

as is a common pattern for generic classes (like IEnumerable - using interfaces), then they all share myBase.

(edit) I just read the actual blog post - and actually, the comment is not really valid in that situation. The "abstract generic base class" he's referring to, Range<T> inherits IEnumerable<T> which inherits non-generic interface IEnumerable. So it's not really an "abstract generic base class." But generally I think it's true.

Answer 2

"Most situations" is outrightly vague. A generic abstract class (or interface) is a bad idea if the only common ancestor between descendants of such class is System.Object (as noted by other commenters of this question).

Otherwise (as in, if you do have a meaningful common ancestor), it's a good idea if you want to "rename" or "specialize" members. Consider this example:

// Meaningful common ancestor for the working classes. interface IWorker {    object DoWork(); }  // Generic abstract base class for working classes implementations. abstract WorkerImpl<TResult> : IWorker {    public abstract TResult DoWork();     object IWorker.DoWork()    {       return DoWork(); // calls TResult DoWork();    } }  // Concrete working class, specialized to deal with decimals. class ComputationWorker : WorkerImpl<decimal> {     override decimal DoWork()     {        decimal res;         // Do lengthy stuff...         return res;     } } 

In this example, DoWork() was redefined in the abstract class, becoming concrete and specialized in ComputationWorker.