Explicitly cast base class to derived class

Question

Problem: I have 2 types which are result sets of 2 different procedures in DB: Proc1Result, Proc2Result (We had to split them - but they are basically the same as comes for input/output)

I then decided that I could make use of an interface to switch between needed procedures on runtime - but this means I would need 1 common type to which i could convert Proc1Result and Proc2Result

Just so I do not need to maintain this new class (create all the properties, add/remove if anything changes in DB result) - I derived this class from one of the results:

public class DerivedClassForInterface : Proc1Result {}

Then I implemented explicit cast from the 2nd proc which works fine, but when I want to implement explicit cast from base class to derived class - it wont allow me (since it kinda already "does" - but it fails at runtime):

public class DerivedClassForInterface : Proc1Result 
{
    //ok - and works as expected
    public static explicit operator DerivedClassForInterface(Proc2Result v)
    {
        return new DerivedClassForInterface
        {
            ...
        };
    }

    //fail: 'user-defined' conversations to or from a base class are not allowed
    public static explicit operator DerivedClassForInterface(Proc1Result v)
    {
        return new DerivedClassForInterface
        {
            ...
        };
    }
}

so this works:

//result2 is of type Proc1Result
DerivedClassForInterface castedResult = (DerivedClassForInterface)result2;
//compiles - works as expected at runtime

but this does not:

//result1 is of type Proc1Result
DerivedClassForInterface castedResult = (DerivedClassForInterface)result1;
//compiles - conversation fails at runtime

So why I can not write my own explicit operator if you can not cast from base class to derived class?

Interesting that compiler allows me to cast from base to derived class, and yet it does not work at runtime.

Probably I will go just for simple functions which will do the "casting" for me. Anyone can suggest a better solution (keep in mind that I would like to keep "DerivedClassForInterface" to obey changes in "Proc1Result" (or "Proc2Result" - doesn't matter))

EDIT
@Peter Duniho - Here the types "Proc1Result" and "Proc2Result" are generated as results from stored procedures (linq2sql). I would like to have a code which I wont need to touch when output of those procedures change (since there are bunch of procedures we need to segment - and implementing new modules could and often does add more output).

Proc1 and Proc2 are basically same stored procedures (they require exactly the same input and provides same output (type-wise not data-wise)). Both of them work with different segments of data and are required to be separate.

Sorry for making this confusing (was at end of my working day...) and not clarifying - the question here actually is:

Why compiler lets me cast from base to derived class when runtime causes exception? And why I can not implement this casting myself (... because it kinda already does - but it just does not work at runtime?)

So from where I stand - it looks the following:
- I can not implement this cast because it already exists
- Yet it is doomed to not work

Here is "Minimal, Complete, and Verifiable code example" (thanks for the link):

//results from stored procedures in database which got splitted appart (linq 2 sql)
class Proc1Result { }
class Proc2Result { }
//

class DerivedClassForInterface : Proc1Result
{
    public static explicit operator DerivedClassForInterface(Proc2Result v)
    {
        //this part would be exported in generic function
        var derivedClassInstance = new DerivedClassForInterface();
        var properties = v.GetType().GetProperties();
        foreach (var property in properties)
        {
            var propToSet = derivedClassInstance.GetType().GetProperty(property.Name);
            if (propToSet.SetMethod != null) propToSet.SetValue(derivedClassInstance, property.GetValue(v));
        }
        return derivedClassInstance;
    }
}

interface IProcLauncher
{
    DerivedClassForInterface GetNeededData();
}

class ProcLauncher1 : IProcLauncher
{
    public DerivedClassForInterface GetNeededData()
    {
        var dataFromDb = new Proc1Result();/*just ilustrative*/
        return (DerivedClassForInterface)dataFromDb;
    }
}

class ProcLauncher2 : IProcLauncher
{
    public DerivedClassForInterface GetNeededData()
    {
        var dataFromDb = new Proc2Result();/*just ilustrative*/
        return (DerivedClassForInterface)dataFromDb;
    }
}


class Program
{
    static void Main(string[] args)
    {
        bool causeInvalidCastException = true;

        IProcLauncher procedureLauncher;
        if (causeInvalidCastException) procedureLauncher = new ProcLauncher1();
        else procedureLauncher = new ProcLauncher2();

        var result = procedureLauncher.GetNeededData();
        Console.WriteLine("I got here!");
    }
}

The idea was:
- Not have to change any code if output of procedures change.
- Decide at runtime which proc to use.
- Export the convertation part as generic function.
- Got to be injectable.

I can solve this - let say - by just 1 generic function which will handle conversation for all cases, but the question is above in bold.

Answer 1

I implemented the converting the following way:

class BaseConverter
{
    protected T Convert<T, X>(X result)
    {
        var derivedClassInstance = Activator.CreateInstance<T>();
        var derivedType = derivedClassInstance.GetType();

        var properties = result.GetType().GetProperties();
        foreach (var property in properties)
        {
            var propToSet = derivedType.GetProperty(property.Name);
            if (propToSet.SetMethod != null)
            {
                propToSet.SetValue(derivedClassInstance, property.GetValue(result));
            }
        }
        return derivedClassInstance;
    }

    protected List<T> Convert<T, X>(List<X> listResult)
    {
        var derivedList = new List<T>();
        foreach (var r in listResult)
        {
            //can cope with this - since there will not ever be many iterations
            derivedList.Add(Convert<T, X>(r));
        }
        return derivedList;
    }
}

So interface implementation classes would inherit from it:

class ProcLauncher2 : BaseConverter, IProcLauncher
{
    public DerivedClassForInterface GetNeededData()
    {
        var dataFromDb = new Proc2Result();/*just ilustrative*/
        //usage (works for single result or list if I need a list returned):
        return Convert<DerivedClassForInterface, Proc2Result>(dataFromDb);
    }

    //other methods...
}

Yet - it is not clear for me - why there is already cast from base class to derived - if that does not work. Imo - it should not be there and throw error at compile time.

Answer 2

I don't understand your question very well. You seem to say that the compiler lets you write the code you posted, but that it fails at runtime. This isn't my experience. I get a compile-time error on the explicit conversion operation for the base class:

error CS0553: 'Derived.explicit operator Derived(Base1)': user-defined conversions to or from a base class are not allowed

Seems pretty clear to me. As for why you aren't allowed to write code like that, you'd have to ask the language designers to know for sure, but it seems like a reasonable restriction to me. There already is a safe, built-in conversion from any base class to a derived class of that base class, as long as the base class instance is in fact an instance of the derived class. It would be confusing and likely to lead to bugs if programmers were allowed to make additional conversions, never mind greatly complicate the language specification's rules for the casting/conversion operator.

As for the broader problem, I don't understand the approach you've chosen. You're designing the classes exactly upside-down from the way one would normally do this. If you have a number of classes that all have shared members, you want to be able to treat all those classes as the same in some context, and you want to be able to implement those shared members exactly once and share them among the other classes, you would put all those members in a single base class, and then derive all your various types from that class.

I don't even see how your current approach addresses this concern:

Just so I do not need to maintain this new class (create all the properties, add/remove if anything changes in DB result)

Since Proc2Result doesn't inherit Proc1Result, if Proc1Result changes, you'll have to go change Proc2Result to match anyway. And any other similar types. And the DerivedClassForInterface class. And you have to change all the explicit operators. How is that better?

I would think you would prefer something like:

class BaseClassForInterface
{
    // declare all shared members here
}

class Proc1Result : BaseClassForInterface { ... }
class Proc2Result : BaseClassForInterface { ... }

Then, for each new Proc...Result class, you simply inherit the base class, no need to re-write the members, and the conversion from each Proc...Result class is trivial. You don't even need to use the casting/conversion operator; the language already knows how to implicitly convert from derived classes to base classes, because the derived classes are the base classes.

This is, in fact, the standard way to use OOP. It's one of the most fundamental features of any OOP language.

If that doesn't get you back on track, you'll need to improve the question, so that it's more clear what you are doing and why. You'll also need to provide a good Minimal, Complete, and Verifiable code example that clearly illustrates your question, explaining precisely what that code does and what you want it to do instead.

Addendum:

Thanks for the edit. Your question is a lot more specific and clear now. I still have questions, but at least I understand the real context.

It seems to me that you already understand most of the basic answer to your question:

Why compiler lets me cast from base to derived class when runtime causes exception? And why I can not implement this casting myself (... because it kinda already does - but it just does not work at runtime?)

So from where I stand - it looks the following:
- I can not implement this cast because it already exists
- Yet it is doomed to not work

I.e. yes, I believe the language disallows this because there is already a built-in cast, and yes the exact approach you seek is doomed to not work.

As far as this part goes:

The idea was:
- Not have to change any code if output of procedures change.
- Decide at runtime which proc to use.
- Export the convertation part as generic function.
- Got to be injectable.

If I understand the first point, this is why you inherit one of the stored procedure types. So that you get the property declarations for free. Seems a little hacky to me, but I admit I do understand the motivation.

As I understand the third point above and your statement after in your post, you already know how you can write a generic method to do the conversion. E.g. something like:

DerivedClassForInterface ConvertToClassForInterface<T>(T t)
{
    DerivedClassForInterface result = new DerivedClassForInterface();
    Type resultType = typeof(DerivedClassForInterface);
    PropertyInfo[] properties = typeof(T).GetProperties();

    foreach (var property in properties)
    {
        var propToSet = resultType.GetProperty(property.Name);
        if (propToSet.SetMethod != null)
        {
            propToSet.SetValue(result, property.GetValue(t));
        }
    }
    return result;
}

I.e. essentially the code you show in your explicit operator (with some minor cleanup/optimization). Or maybe you aren't using the term "generic" literally, and just mean "general purpose". Obviously there's very little in the above that really benefits from the method being generic; you could just as easily use GetType() on the parameter, just as your explicit operator does.

Unfortunately, I don't know how the criteria "Got to be injectable" fits in here. Injectable, how? Do you mean you want to inject the code somewhere else? Or do you mean that the code needs to be compatible with an AOP system, or some other form of code injection applied to it?

Ignoring that part, which I don't understand, I would actually just leverage the compiler and runtime to do all the heavy lifting for me (including caching the reflection stuff, which in your code is going to be very slow). You could write a class like this:

class Wrapper
{
    private dynamic _data;

    public string Value {  get { return _data.Value; } }

    public Wrapper(dynamic data)
    {
        _data = data;
    }
}

Given a couple of other classes like this:

class Result1
{
    public string Value { get; set; }
}

class Result2
{
    public string Value { get; set; }
}

Then you can use it like this:

Result1 r1 = new Result1 { Value = "result 1" };
Result2 r2 = new Result2 { Value = "result 2" };
Wrapper w1 = new Wrapper(r1), w2 = new Wrapper(r2);

Console.WriteLine("w1 result: " + w1.Value);
Console.WriteLine("w2 result: " + w2.Value);

I.e. just create an instance of Wrapper, passing the relevant object (in your case, this would be the generated type's from the stored procedure). The downside is, of course, that you do have to add properties to the Wrapper type to match your stored procedure. But I'm not convinced that's a bad thing. Even if you've somehow arranged it so that none of the rest of the code has to change, it's a relatively minor maintenance task.

And I suspect that altering the stored procedure requires changes elsewhere in the code anyway, to explicitly refer to the properties. Because after all, if the rest of the code is similarly completely agnostic regarding the specific class members (i.e. uses reflection all the way), then you could just pass the result objects around as object types, and not worry about the wrapper at all.