Question

Additional information

I appreciate the attempts to redefine the problem but the structure in question is non negotiable. I’m working with a code base created in 2004 in .NET 1.1 before generics and a lot of other nice features. I cannot break the existing model – only enhance it (hence the conversion of C to C – in totality its actually C : C where C is maintained only to preserve existing inheritance dependencies.

Our 8 year old data layer is a poor man’s ORM – it encapsulates Entity functionality (ie: the table fields) and data functionality (connecting and pulling data) in one class. Abstract Generic C and abstract B are generated by a utility app we have used since 2004. That’s why B is abstract – so developers are forced to think about the real instantiation of B as type A. (Which was not fully successful, admittedly)

There are over 100 tables in this model, and so over 100 “A” classes in our projects. I cannot adopt any change that will require every single A class to be manually updated. Any changes I make must be done in a generated fashion – and ideally as low down the inheritance root as possible.

The existing select methods return data sets, not themselves. If I am to improve them at all it is only to make them use data readers and return instances of and lists of themselves.

SO thank you to those who’ve replied so far, but what would actually help me here is an answer to the problem presented, not attempts to redefine the problem to suit what would be ideal in a new app.

---

Original content:

I have a base abstract generic class C

public abstract class C<T>

from it is derived an abstract class B

public abstract class B : C<B>

And finally A instantiates B

public class A : B

B has methods which return a list of B, that needs to be able to invoke an instance of C to populate the list. I want the method to instance this 2nd generation descendent to reside in C.

public abstract class C<T>
{
    protected abstract PopulateList(List<T> theList, SqlDataReader dr);
    protected TI GetNew<TI>() where TI:T, new() {return new TI();}
}

SO far so good, but now in B I need the PopulateList method to be able to instance new A objects to fill them from a datareader that provides data common to B

public abstract class B : C<B>
{
    public int MyInt {get;set;}

    protected override void PopulateList(List<B> DistributionList, SqlDataReader dr)
    {
        while (dr.Read())
        {
            Distribution newOne = GetNew<B>();

            newOne.MyInt = (Int32)dr["MyInt"];
            DistributionList.Add(newOne);
        }
    }
}

So do I need to make B generic as well? B<T> : C<T> where T:B and reproduce populate list in the same manner as GetOne()? Or is there some way I can force PopulateList to invoke new instances of the current type derived from B without adding a new layer of generics?

Not that a new layer of generics is bad per se- just not preferred in this instance

Answer 1

You can achieve this without more generics if you’re willing to make this change to GetNew() in class C<T>:

protected abstract T GetNew();

In B.PopulateList:

B newOne = GetNew();

And in class A:

protected override B GetNew()
{
    return new A();
}

UPDATE: If it isn’t practical to make any changes to class A, then you can instead define GetNew() in C<T> as follows:

protected T GetNew()
{
    return (T)Activator.CreateInstance(this.GetType());
}

Inelegant, yes, but it gets the job done.