泛型列表类继承设计困扰：子类属性隐藏父类属性的问题咨询

这确实是继承场景中很容易踩的坑——用new关键字隐藏基类属性会导致多态视角下的行为不一致，当你把SpecialDocument当作Document来用的时候，访问到的完全是另一个独立的List<Result>，和子类的SpecialResult列表毫无关系，这显然违背了继承的多态预期。

最优方案：泛型基类+类型约束 #

我们可以把基类改成泛型类，让子类在继承时指定具体的Result子类类型，从根源上避免属性隐藏的问题：

// 泛型基类，通过类型约束确保TResult是Result的子类
public class Document<TResult> where TResult : Result
{
    public List<TResult> Results { get; } = new List<TResult>();
}

// 基础Result类保持不变
public class Result { }

// 子类继承时明确指定SpecialResult作为泛型参数
public class SpecialDocument : Document<SpecialResult> { }

public class SpecialResult : Result { }

为什么这个方案更好？ #

• 无歧义的类型安全：SpecialDocument的Results直接是List<SpecialResult>，不需要任何强制转换，也不会和基类属性产生混淆。
• 真正的多态支持：如果需要统一处理所有类型的Document，可以额外定义一个非泛型的接口或抽象类作为顶层，兼顾强类型和统一操作：

// 非泛型接口，用于统一访问所有Document的结果集合
public interface IDocument
{
    IEnumerable<Result> GetResults();
}

// 泛型基类实现接口，提供强类型的Results属性和统一的访问方式
public class Document<TResult> : IDocument where TResult : Result
{
    public List<TResult> Results { get; } = new List<TResult>();

    public IEnumerable<Result> GetResults()
    {
        return Results;
    }
}

这样，当你需要批量处理不同类型的Document时，只需通过IDocument接口调用GetResults()就能拿到所有Result实例；而在处理具体的SpecialDocument时，又能直接使用强类型的List<SpecialResult>，完美平衡了两种场景的需求。

避坑提醒 #

永远尽量避免用new关键字隐藏基类成员——它本质上是在子类中创建了一个和基类同名的全新成员，而非覆盖基类行为，这种设计几乎总会在多态场景下引发逻辑错误，就像你遇到的这个问题一样。如果必须兼容原有非泛型的Document类（比如它是第三方依赖），可以考虑用组合模式替代继承，或者增加一个适配器层来转换类型，但泛型基类无疑是最干净、最符合面向对象设计的解决方案。

内容的提问来源于stack exchange，提问作者Manuel Faux