C# 更改子类中抽象属性的返回类型

Question

TLDR: Is there anyway to override an abstract property and change it's return type at the same time, just like you can do with concrete properties? I know the direct answer is "no", but I'm wondering if there's any workaround that doesn't involve adding a second property.

Let's say I have this abstract class:

public abstract class Item {
  public abstract string SerialNumber { get; }
  public string PartNumber => "34";
}

Let's say I want a Toy class that implements Item . Let's also say for some reason I want the SerialNumber and PartNumber properties to both be int values in the child class even though they are strings on the base. See below:

public abstract class Toy {
  public override int SerialNumber => 5; //Doesn't compile obviously
  public new int PartNumber => int.ParseInt(base.PartNumber); //works fine, refines the type but keeps the value
}

I included PartNumber just to show that I understand how the new keyword is supposed to work. That part works fine for me.

My question is: Is there any way to both override AND refine the type of SerialNumber at the same time? I understand what I have above doesn't work, but I'm looking for a simple workaround. The goal is to NOT use an extra property (like SerialNumberInt or something) so that the Toy class's methods can refer to SerialNumber and get it as an int.

Thanks!

Answer 1

What you're trying to do is not possible.

The reason for this is that your base class expresses a contract, part of which is the return type of methods it exposes.

Your subclass cannot fulfill this contract: suppose you have a class "ItemSubmitter", which has a method "submitItem", which internally does:

   string partNumberToSubmit = item.PartNumber;

Since item.PartNumber in your example returns an int, this would cause an exception. How would you expect the compiler to deal with this situation?

So, it is not possible. This concept is generalized as the Liskov Substitution Principle from Barbara Liskov, see eg https://en.wikipedia.org/wiki/Liskov_substitution_principle .

You could use generics, but this would require all base class consumers to also be generic. In this case I'd question if you need a base class at all and simply make the consumers generic.

See also C# Override abstract property with concrete property

It appears you've answered your own question (stated differently) some time ago: https://stackoverflow.com/a/40657803/11389043

Answer 2

This can be done using Generics. But before you do it you need to be sure you are approaching your problem correctly. That said, I've used the below idea to map domain entities with common properties but they have different Type s for their entity id.

public abstract class ItemBase<TId>
{
    protected ItemBase(TId id)
    {
        ItemId = id;
    }
    public TId ItemId { get; }

}

public class Toy : ItemBase<int>
{
    public Toy(int id) : base(id)
    {

    }
}

public class NotAToy : ItemBase<Guid>
{
    public NotAToy(Guid id) : base(id)
    {

    }
}

Answer 3

You can do that using generics (see below) or you could just make everything an object. However, this really doesn't feel like a great solution but I don't know the purpose behind arbitrarily changing the types in this case.

public abstract class Item <T,V>
{
    public abstract T SerialNumber { get; }
    public V PartNumber { get; }
}

public abstract class Toy : Item<int, int>
{
    public override int SerialNumber => 5; 
    public new int PartNumber => int.Parse(base.PartNumber.ToString()); 
}
public abstract class ToyString : Item<string, string>
{
    public override string SerialNumber => "3";
    public new string PartNumber => "34";
}

Answer 4

You can use generics to achieve this as follows:

public abstract class Item<T> {
  public abstract T SerialNumber { get; }
}
public  class Toy : Item<int> {
  public override int SerialNumber => 5;
}

However, you shouldn't necessarily do this. You may want to confirm if this design is appropriate in your case since if you are redefining types on derived classes then it's most likely a problem with how you are defining your base class.