Problem with Covariant return types from an abstract method

Question

I’m trying to wrap up a two day beat down on Abstract methods and return type Covariance, I’ve already posted two similar questions and I am eternally grateful to the community for the info provided, I just need one last push to get to the finish line. Here is what I am trying to do: 2 abstract classes, RecruiterBase and CandidateBase, both have concreate implementations of RecruiterA and CandidateA. RecruiterBase has an abstract method to get all recruited candidates returning IQueryable. My implementation of RecruiterA overrides the GetCandidates() method to return IQueryable.

public abstract class RecruiterBase
{ 
  // Constructors declared here

  public abstract IQueryable<CandidateBase> GetCandidates();
}

public abstract class CandidateBase
{  
  // Constructors declared here
}

and the implementations:

public class CandidateA : CandidateBase
{
  // Constructors declared here
}

public class RecruiterA : RecruiterBase
{
  // Constructors declared here

  // ----HERE IS WHERE I AM BREAKING DOWN----
  public override IQueryable<CandidateA> GetCandidates()
  {
     return from c in db.Candidates
            where c.RecruiterId == this.RecruiterId
            select new CandidateA
            {
              CandidateId = c.CandidateId,
              CandidateName = c.CandidateName,
              RecruiterId = c.RecruiterId
            };
  }
}

Attempting to complile that throw a compile time error because in my implementation of RecruitreBase the GetCandidates() method returns IQueryable<CandidateA> instead of IQueryable<CandidateBase>.

After not being able to get the suggestions from a previous question (Generic return types from abstract/virtual methods) to work, I did a LOT more reading, and came across the following question in SO

How to return subtype in overridden method of subclass in C#?

Which finally made me realize what I had been searching for was a way to implement Covariance for my return type. I used Marc Gravell's snippet...

abstract class BaseClass
{
    public BaseReturnType PolymorphicMethod()
    { return PolymorphicMethodCore();}

    protected abstract BaseReturnType PolymorphicMethodCore();
}

class DerivedClass : BaseClass
{
    protected override BaseReturnType PolymorphicMethodCore()
    { return PolymorphicMethod(); }

    public new DerivedReturnType PolymorphicMethod()
    { return new DerivedReturnType(); }
}

... as the basis for my solution. So now my RecruiterBase and RecruiterA classes look like:

public abstract class RecruiterBase
{
  // Constructors declared here

  public IQueryable<CandidateBase> GetCandidates()
  {
     return GetCandidatesCore();
  }

  public abstract IQueryable<CandidateBase> GetCandidatesCore();
}

and my implementation...

public class RecruiterA : RecruiterBase
{
  // Constructors

  protected override IQueryable<CandidateBase> GetCandidatesCore()
  {
    return GetCandidates();
  }

  public new IQueryable<CandidateA> GetCandidates()
  {
    return from candidates in db.Candidates
           select new CandidateA
           {
             CandidateId = candidates.CandidateId,
             RecruiterId = candidates.RecruiterId
           };
  }
}

I was hoping that would finally get me what I was looking for but I got a compile time error in the following code because GetCandidates() cannot implicitly convert CandidateA to CandidateBase:

  protected override IQueryable<CandidateBase> GetCandidatesCore()
  {
    return GetCandidates();
  }

so I added a cast:

  protected override IQueryable<CandidateBase> GetCandidatesCore()
  {
    return ((IQueryable<CandidateBase>)GetCandidates());
  }

Everything then compiles but when I actually call GetCandidates() in my controller it returns IQueryable<CandidateBase> instead of IQueryable<CandidateA>. So I am right back where I started.

If you made it all the way through this and you can help me I'll send you a 12 pack of your favorite beer!

Answer 1

Justin I am a little bit confused why you need to go through all that trouble.

If you abstract method is of return type IQueryable<CandidateBase> then that's what you'll get. I don't see a problem with this, since later on you could still cast it back to CandidateA or CandidateB

So what exactly are you trying to achieve? Maybe I am not understanding you question.

Edit to add:

Justin, what about this?

public abstract class RecruiterBase<T>
    {
        // Constructors declared here

        public abstract IQueryable<CandidateBase> GetCandidates();
    }

    public abstract class CandidateBase
    {
        // Constructors declared here
    }


    public class CandidateA : CandidateBase
    {

    }

    public class RecruiterA : RecruiterBase<RecruiterA>
    {
        // Constructors declared here

        // ----HERE IS WHERE I AM BREAKING DOWN----
        public override IQueryable<CandidateBase> GetCandidates()
        {
            return db.Candidates.Where(cand => cand.RecruiterId == this.RecruiterId)
                         .Select(x => new CandidateA
                                          {
                                             CandidateId = c.CandidateId,
                                             CandidateName = c.CandidateName,
                                             RecruiterId = c.RecruiterId
                                           })
                         .Cast<CandidateBase>()
                         .AsQueryable();
        }
    }

Answer 2

I think your intentions are good, but the net result is that you're missing the point of polymorphic code and also losing the value.

The purpose of working with objects by their abstract type or by their interfaces is to allow you to work with any concrete implementation, without needing to know any concrete implementation details. I think your belief is that by returning concrete types you are producing higher-quality code, when in fact you're beginning to negate the value of the abstract base class by covering up the abstraction.

A properly built set of derived classes should have only very few needs to be addressed by their concrete types; the abstract class should suffice for working with all implementations and should handle the vast majority of work with those classes--the exceptions should be in the minority.