Options for class design using safe downcasting

Question

After struggling with downcasting (see [my original post]) and with making [deep copies], I found [this eponymous article] where a suggestion is made in C++ as to how to deal with the issue. With much excitement I implemented it in C# as follows:

public partial class User
{
virtual public Employer GetEmployer() { return null; }
...
}

public partial class Employer
{
public override Employer GetEmployer() { return this; }
...
}

which I then used like this:

User u = GetUser();
Employer e = u.GetEmployer();

However (I suppose, not surprisingly), the override is never called and a null is returned.

---

The problem I'm trying to solve is what I gather would be a very common use-case: I get a bit of data I need to store but it's incomplete. Later I get more data and I use it to refine (downcast) my understanding of the world.

In this particular case, I get an e-mail address from someone using my website so I know they are a User, but in general I don't know anything else about them. Later (when they fill out a form), I know that they are actually an Employer, so I need to downcast my User.

What is the right approach here?

Answer 1

I answered one of your former questions. You are trying to solve something which cannot be solved. The solution here is not to use inheritance. Why because inheritance is is a relationship. So if you have:

public class User { }

public class Employee : User { }

You have this relations Employeee is User but you don't have reverse relationship User is Employee. But that is exectly what you are trying to do with casting from User to Employee. Instance of User cannot be cast to Employee (except the situation I mentioned in my previous answer - but you don't have this situation).

Use this approach and you will solve it in object oriented way without needs for inheritance casting or what ever else.

public class User 
{
    public virtual EmployeeData { get; set; }
}

public class EmployeeData { }

The approach changes your design from is a to has a relationship. EmployeeData in this case is separate entity mapped in 1 - 0..1 relation (that will result in two tables in the database). You can also use 1 - 1 relation or ComplexType if you are happy with the fact that both User and EmployeeData will be stored in the same table.

Answer 2

The only missing part of your example is that Employer doesn't inherit from User.

Change your declaration to:

public partial class Employer : User
{
    // ...
}

And you should be good to go. I'm not sure I would go this route though. I would probably simply use the as keyword to do my casting safely:

var user = GetUser();
var employer = user as Employer;

// if the cast failed, employer will be null
if(employer != null)
{
    // Work with employer
}

Answer 3

You should follow the State Pattern:

This is a clean way for an object to partially change its type at runtime.

You can then mix-and-match with the Prototype Pattern:

[Use] a prototypical instance, which is cloned to produce new objects.

You could thus get something like this:

// State pattern: public "wrapper"
public class User {
    UserState state = UserState.CreateUser();

    public void SetIsEmployer ()
    {
        // Use UserState.IsEmployer() method to transition to the
        // Employer state
        state = state.IsEmployer ();
    }

    public User Employer {
        get {return state.Employer.User;}
    }
}

// State pattern: User state
internal class UserState {
    // protected so that only CreateUser() can create instances.
    protected UserState ()
    {
    }

    public User User {
        get {/* TODO */}
    }

    public virtual UserState Employer {
        get {return null;}
    }

    // Creates a default prototype instance
    public static UserState CreateUser ()
    {
         return new UserState ();
    }

    // Prototype-ish method; creates an EmployerState instance
    public virtual UserState IsEmployer ()
    {
        return new EmployerState (/* data to copy...*/);
    }
}

// State pattern: Employer state
class EmployerState : UserState {
    internal EmployeeState ()
    {
    }

    public override UserState Employer {
        get {return this;}
    }
}

If your public User type needs more "state transitions," you need only provide more classes (one for each state) and prototype-ish methods on the UserState type to create the appropriate target state type. User.state is always the current state of the User. This setup allows you to change the apparent runtime type of an instance at runtime.