使用标记接口而不是属性的令人信服的理由

Question

之前在 Stack Overflow 上讨论过我们应该更喜欢属性而不是标记接口（没有任何成员的接口）。 MSDN 上的界面设计文章也提出了此建议：

避免使用标记接口（没有成员的接口）。

自定义属性提供了一种标记类型的方法。有关自定义属性的更多信息，请参阅编写自定义属性。当您可以将属性检查推迟到代码执行时，自定义属性是首选。如果您的场景需要编译时检查，则无法遵守此准则。

甚至还有一个 FxCop 规则来强制执行此建议：

避免空接口

接口定义提供行为或使用契约的成员。接口描述的功能可以被任何类型采用，无论该类型出现在继承层次结构中的哪个位置。类型通过提供接口成员的实现来实现接口。空接口不定义任何成员，因此不定义可以实现的契约。

如果您的设计包含预期类型要实现的空接口，则您可能正在使用接口作为标记，或者识别一组类型的方法。如果此识别将在运行时发生，则完成此操作的正确方法是使用自定义属性。使用属性的存在或不存在或属性的特性来识别目标类型。如果必须在编译时进行识别，则可以使用空接口。

本文只说明了您可能会忽略该警告的一个原因：当您需要类型的编译时识别时。 （这与界面设计文章一致）。

如果接口用于在编译时识别一组类型，则可以安全地从该规则中排除警告。

真正的问题来了：微软在框架类库的设计中没有遵循他们自己的建议（至少在一些情况下）：IRequiresSessionState 接口 和 IReadOnlySessionState 接口。 ASP.NET 框架使用这些接口来检查是否应该为特定处理程序启用会话状态。显然，它不用于编译时类型识别。为什么他们不这样做？我可以想到两个潜在的原因：

1. 微优化：检查对象是否实现接口（obj is IReadOnlySessionState）比使用反射检查属性（type. IsDefined(typeof(SessionStateAttribute), true))。大多数情况下，这种差异可以忽略不计，但对于 ASP.NET 运行时中的性能关键代码路径来说，它实际上可能很重要。但是，他们可以使用一些解决方法，例如缓存每种处理程序类型的结果。有趣的是，ASMX Web 服务（具有类似的性能特征）实际上使用 WebMethod 属性 用于此目的。

2. 第三方 .NET 语言实现接口可能比使用属性修饰类型更受支持。由于 ASP.NET 被设计为与语言无关，并且 ASP.NET 生成类型代码（可能在 CodeDom），它基于 <%@ Page %> 指令，使用接口而不是属性可能更有意义.

使用标记接口而不是属性的有说服力的理由是什么？

这只是一个（过早的？）优化还是框架设计中的一个小错误？ （他们是否认为反射是一个“红眼睛的大怪物”？）想法？

Answer 1

我通常会避免使用“标记接口”，因为它们不允许您取消标记派生类型。但除此之外，以下是我见过的一些特定情况，其中标记接口比内置元数据支持更可取：

1. 运行时性能敏感的情况。
2. 与不支持注释或属性的语言的兼容性。
3. 感兴趣的代码可能无法访问元数据的任何上下文。
4. 支持通用约束和通用方差（通常是集合）。

Answer 2

对于泛型类型，您可能希望在标记接口中使用相同的泛型参数。这是通过属性无法实现的：

interface MyInterface<T> {}

class MyClass<T, U> : MyInterface<U> {}

class OtherClass<T, U> : MyInterface<IDictionary<U, T>> {}

这种接口对于将一种类型与另一种类型相关联可能很有用。

标记界面的另一个很好的用途是当您想要创建 种类时mixin：

interface MyMixin {}

static class MyMixinMethods {
  public static void Method(this MyMixin self) {}
}

class MyClass : MyMixin {
}

非循环访问者模式也使用它们。有时也使用术语“简并接口”。

更新：

我不知道这是否重要，但我已经用它们来标记 后编译器 来工作。

Answer 3

微软在制作.NET 1.0时并没有严格遵循准则，因为准则是随着框架一起演变的，有些规则他们直到更改API时才了解到，为时已晚。

IIRC，你提到的例子属于BCL 1.0，这样就可以解释了。

框架设计指南对此进行了解释。

---

也就是说，该书还指出“属性测试比类型检查的成本要高得多”（在 Rico Mariani 的侧边栏中）。

它接着说，有时您需要标记接口来进行编译时检查，而这对于属性来说是不可能的。不过，我觉得书中给出的例子（第88页）缺乏说服力，所以这里不再重复。

Answer 4

我非常支持标记接口。我从来不喜欢属性。我将它们视为类和成员的某种元信息，供调试器查看。与异常类似，在我看来，它们不应该影响正常的处理逻辑。

Answer 5

从性能角度来看：

由于反射，标记属性将比标记接口慢。如果您不缓存反射，则始终调用 GetCustomAttributes 可能会成为性能瓶颈。我之前对此进行了基准测试，即使在使用缓存反射时，使用标记接口在性能方面也能获胜。

这只适用于在经常调用的代码中使用它的情况。

BenchmarkDotNet=v0.10.14, OS=Windows 10.0.16299.371 (1709/FallCreatorsUpdate/Redstone3)
Intel Core i5-2400 CPU 3.10GHz (Sandy Bridge), 1 CPU, 4 logical and 4 physical cores
Frequency=3020482 Hz, Resolution=331.0730 ns, Timer=TSC
.NET Core SDK=2.1.300-rc1-008673
  [Host] : .NET Core 2.0.7 (CoreCLR 4.6.26328.01, CoreFX 4.6.26403.03), 64bit RyuJIT
  Core   : .NET Core 2.0.7 (CoreCLR 4.6.26328.01, CoreFX 4.6.26403.03), 64bit RyuJIT

Job=Core  Runtime=Core

                     Method |          Mean |      Error |     StdDev | Rank |
--------------------------- |--------------:|-----------:|-----------:|-----:|
                     CastIs |     0.0000 ns |  0.0000 ns |  0.0000 ns |    1 |
                     CastAs |     0.0039 ns |  0.0059 ns |  0.0052 ns |    2 |
            CustomAttribute | 2,466.7302 ns | 18.5357 ns | 17.3383 ns |    4 |
 CustomAttributeWithCaching |    25.2832 ns |  0.5055 ns |  0.4729 ns |    3 |

但这并没有显着差异。

namespace BenchmarkStuff
{
    [AttributeUsage(AttributeTargets.All, AllowMultiple = false)]
    public class CustomAttribute : Attribute
    {

    }

    public interface ITest
    {

    }

    [Custom]
    public class Test : ITest
    {

    }

    [CoreJob]
    [RPlotExporter, RankColumn]
    public class CastVsCustomAttributes
    {
        private Test testObj;
        private Dictionary<Type, bool> hasCustomAttr;

        [GlobalSetup]
        public void Setup()
        {
            testObj = new Test();
            hasCustomAttr = new Dictionary<Type, bool>();
        }

        [Benchmark]
        public void CastIs()
        {
            if (testObj is ITest)
            {

            }
        }

        [Benchmark]
        public void CastAs()
        {
            var itest = testObj as ITest;
            if (itest != null)
            {

            }
        }

        [Benchmark]
        public void CustomAttribute()
        {
            var customAttribute = (CustomAttribute)testObj.GetType().GetCustomAttributes(typeof(CustomAttribute), false).SingleOrDefault();
            if (customAttribute != null)
            {

            }
        }

        [Benchmark]
        public void CustomAttributeWithCaching()
        {
            var type = testObj.GetType();
            bool hasAttr = false;
            if (!hasCustomAttr.TryGetValue(type, out hasAttr))
            {
                hasCustomAttr[type] = type.CustomAttributes.SingleOrDefault(attr => attr.AttributeType == typeof(CustomAttribute)) != null;
            }
            if (hasAttr)
            {

            }
        }
    }

    public static class Program
    {
        public static void Main(string[] args)
        {
            var summary = BenchmarkRunner.Run<CastVsCustomAttributes>();
        }
    }
}

Answer 6

从编码的角度来看，我认为我更喜欢标记接口语法，因为内置关键字 as 和 is。属性标记需要更多的代码。

[MarkedByAttribute]
public class MarkedClass : IMarkByInterface
{
}

public class MarkedByAttributeAttribute : Attribute
{
}

public interface IMarkByInterface
{
}

public static class AttributeExtension
{
    public static bool HasAttibute<T>(this object obj)
    {
        var hasAttribute = Attribute.GetCustomAttribute(obj.GetType(), typeof(T));
        return hasAttribute != null;
    }
}

以及使用代码的一些测试：

using Microsoft.VisualStudio.TestTools.UnitTesting;

[TestClass]
public class ClassMarkingTests
{
    private MarkedClass _markedClass;

    [TestInitialize]
    public void Init()
    {
        _markedClass = new MarkedClass();
    }

    [TestMethod]
    public void TestClassAttributeMarking()
    {
        var hasMarkerAttribute = _markedClass.HasAttibute<MarkedByAttributeAttribute>();
        Assert.IsTrue(hasMarkerAttribute);
    }

    [TestMethod]
    public void TestClassInterfaceMarking()
    {
        var hasMarkerInterface = _markedClass as IMarkByInterface;
        Assert.IsTrue(hasMarkerInterface != null);            
    }
}