C#中子类隐藏父类成员类型的实现是否合规？是否违反SOLID原则？

问题背景 #

我们需要设计两个类：Context和Context<T>，其中Context的MainObject成员为dynamic（或object）类型，用于不需要在编译时知晓具体类型的场景；Context<T>则明确MainObject的具体类型，供需要强类型的场景使用。核心需求是：

• 像Serialize这类无需知道MainObject具体类型的方法，接收Context作为参数
• 像ResolveUiWidget这类需要强类型的方法，接收Context<UiWidget>作为参数
• var context = new Context<UiWidget>(); Serialize(context)这类调用必须合法

当前实现代码 #

public class Context
{
    public virtual dynamic? MainObject { get; set; }
}

public class Context<T>: Context
{
    public new T? MainObject { get; set; }

    public Context()
    {
        MainObject = base.MainObject;
    }
}

核心疑问 #

这种实现是否存在问题？是否违反SOLID原则？尤其是里氏替换原则（LSP）？有没有更合理的替代方案满足需求？

问题分析 #

1. 明确违反里氏替换原则 #

当前实现最大的问题是用new关键字隐藏了基类的MainObject成员，而非重写。这导致基类和子类的MainObject是完全独立的两个成员，当用基类引用指向子类实例时，会出现行为不一致的情况：

// 用基类引用指向子类实例
Context baseContext = new Context<UiWidget>();
// 修改基类的MainObject
baseContext.MainObject = new SomeOtherType();
// 转换回子类类型
var typedContext = (Context<UiWidget>)baseContext;
// 此时typedContext.MainObject仍然是null，和基类的MainObject完全脱节

里氏替换原则要求子类实例可以在任何使用基类的场景中替换，且行为与基类一致。但这里子类实例作为基类使用时，修改基类成员不会同步到子类的强类型成员，完全违背了LSP的要求。

2. 维护性隐患 #

两个独立的MainObject成员极易造成开发者混淆，误以为它们是同一个值的不同类型视图，从而引发难以排查的bug。

替代方案 #

方案1：重写+强类型访问器（推荐） #

让子类重写基类的MainObject，同时提供强类型的访问器，共享同一个底层字段，保证数据一致性：

public class Context
{
    public virtual object? MainObject { get; set; }
}

public class Context<T> : Context
{
    private T? _mainObject;

    // 重写基类的MainObject，做类型校验
    public override object? MainObject
    {
        get => _mainObject;
        set => _mainObject = value is T validValue ? validValue : throw new InvalidCastException($"无法将{value?.GetType().Name}赋值给{typeof(T).Name}类型");
    }

    // 提供强类型的访问器，隐藏基类的属性（但底层用同一个字段）
    public new T? MainObject
    {
        get => _mainObject;
        set => _mainObject = value;
    }
}

这种方式下，无论是通过基类引用还是子类引用操作MainObject，都会同步到同一个字段，符合LSP要求，同时保留了强类型的便利性。

方案2：基于接口的设计 #

利用接口分离原则（ISP），定义两个接口分别对应无类型和强类型的场景：

public interface IContext
{
    object? MainObject { get; set; }
}

public interface IContext<T> : IContext
{
    new T? MainObject { get; set; }
}

public class Context<T> : IContext<T>
{
    private T? _mainObject;

    // 显式实现IContext接口
    object? IContext.MainObject
    {
        get => _mainObject;
        set => _mainObject = value is T validValue ? validValue : throw new InvalidCastException();
    }

    // 强类型的公开属性
    public T? MainObject
    {
        get => _mainObject;
        set => _mainObject = value;
    }
}

此时Serialize方法接收IContext，ResolveUiWidget接收IContext<UiWidget>，既满足了参数需求，又保证了数据一致性，同时接口设计更灵活，符合SOLID的ISP原则。

方案3：只读基类（适合无需修改的场景） #

如果不需要通过基类修改MainObject，可以将基类设计为只读，子类实现强类型的读写：

public abstract class Context
{
    public abstract object? MainObject { get; }
}

public class Context<T> : Context
{
    public T? MainObject { get; set; }
    public override object? MainObject => MainObject;
}

这种方式避免了类型转换异常，同时满足LSP，适合仅需读取MainObject的无类型场景。

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