Abstract generic classes taking type parameters that are themselves derived from that class

Question

Do you consider it an acceptable or a bad practice to create an abstract generic class that takes as a type parameter a class that derives from itself?

This allows the abstract generic class to manipulate instances of the derived class and in particular the ability to create new() instances of the derived class as necessary and can help avoid repeat code in the concrete classes that derive from it.

If 'bad' what alternative do you prefer to handle such situations and how would you structure the code below?

For example:-

    // We pass both the wrapped class and the wrapping class as type parameters 
    // to the generic class allowing it to create instances of either as necessary.

    public abstract class CoolClass<T, U>
        where U : CoolClass<T, U>, new()
    {
        public T Value { get; private set; }
        protected CoolClass() { }
        public CoolClass(T value) { Value = value; }
        public static implicit operator CoolClass<T, U>(T val)
        {
            // since we know the derived type and that its new(), we can
            // new up an instance of it (which we couldn't do as an abstract class)
            return new U() { Value = val};
        }
        public static implicit operator T(CoolClass<T, U> obj)
        {
            return obj.Value;
        }
    }

And a second bonus question: why does ONE of these implicit operators work and the other one not?

e.g.

    public class CoolInt : CoolClass<int, CoolInt>
    {
        public CoolInt() {  }
        public CoolInt(int val) (val) { }
    }

                                    // Why does this not work
        CoolInt x = 5;
                                    // when this works
        CoolInt x2 = (CoolInt)5;    
                                    // and this works
        int j = x;

Answer 1

It is a bit subjective but I'm not a big fan of the implicit casts. Code often becomes misleading when you use them and sometimes it is hard to find a bug if it is cause by implisit casts. If your class is designed only for use of them than I wouldn't use it in this way.

why does ONE of these implicit operators work and the other one not?

Because you defined convertion from CoolClass<T, U>, but not from the CoolInt. They are different types. It would work if you had this method in your CoolInt implementation:

public static implicit operator CoolInt(int val)

About usage of generics:

Such usage of generics creates limitations to your architecture if you would need to create complex inheritance hierarchies with many classes (e.g. introducing new level of abstraction could be tricky). But this really depends on what you need. I actually used such tecnique in one of the projects to avoid code duplication. Also you could pass a delegate Func<U> to the constructor if your CoolClass to overcome new() restriction :)

Answer 2

It's a common (and good!) pattern in C++, that looks a little like this:

template<typename T> class Base {
    void foo() { T::foo(); /* Call the derived implementation*/ }
};
class Derived : public Base<Derived> {
    void foo() { /* do something*/ }
};

We use it for static polymorphism/inheritance, along with others.

However, in .NET where generic parameters are at runtime and there is also reflection, I'm not entirely sure where the benefit would be. I mean, having the derived type is useful, but you have to ask yourself- useful for what, and how does it differ from straight inheritance?