通过属性标记还是拆分接口实现特性？求方案1的支持依据

针对仅约50%类需要实现的特性，方案1（单接口加属性标记）在以下场景中会比方案2（拆分接口）更具优势：

1. 简化调用方逻辑 #

如果业务中大部分调用场景需要同时处理通用方法（OtherMethod）和可选特性（FeatureX），方案1的调用代码会更连贯。调用方无需频繁做类型判断与转换，直接通过属性即可知晓是否能调用FeatureX：

// 方案1调用示例
public void ProcessEntity(Foo entity)
{
    entity.OtherMethod();
    if (entity.HasFeatureX)
    {
        entity.FeatureX();
    }
}

对比方案2，调用方需要先判断实例是否实现了Foo接口，再做类型转换，代码步骤更多：

// 方案2调用示例
public void ProcessEntity(Bar entity)
{
    entity.OtherMethod();
    if (entity is Foo fooEntity)
    {
        fooEntity.FeatureX();
    }
}

2. 保留业务逻辑的内聚性 #

如果FeatureX与OtherMethod在业务语义上强关联——比如两者同属某个业务实体的行为集合，只是部分实体不需要FeatureX的具体实现——方案1的单接口能更好地体现这种关联性，避免因拆分接口割裂业务逻辑，让代码结构更贴合业务场景。

3. 降低现有代码的改造成本 #

如果项目中已经存在大量基于Foo接口的调用代码，改用方案2需要全面修改这些调用点（将参数类型从Foo改为Bar，并添加类型判断逻辑），改造成本极高。而方案1仅需在实现类中补充HasFeatureX的返回值（无需FeatureX的类返回false，FeatureX方法可做空实现或抛出NotSupportedException），现有调用代码几乎无需改动。

4. 更直观的可选特性语义 #

HasFeatureX属性直接明确了“该特性为可选”的语义，阅读代码的开发者能立刻理解FeatureX并非所有实现类都支持。而方案2需要通过“是否实现特定接口”间接推断特性的可选性，语义表达更隐晦，增加了后续维护的理解成本。

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