空接口有代码味道吗？ [关闭]

我有一个函数返回相同类型的对象（查询结果），但没有共同的属性或方法。为了拥有一个通用类型，我使用一个空接口作为返回类型，并在两者上“实现”它。

这听起来当然不对。我只能通过坚持希望有一天这些类会有一些共同点来安慰自己，并且我会将这些共同逻辑移至我的空界面中。但我并不满足，并思考是否应该有两种不同的方法并有条件地调用 next。这是一个更好的方法吗？

我还被告知 .NET Framework 使用空接口来进行标记。

我的问题是：空接口是设计问题的强烈标志还是它被广泛使用？

EDIT：对于那些感兴趣的人，我后来发现函数式语言中的可区分联合是我想要实现的目标的完美解决方案。 C# 似乎对这个概念还不太友好。

EDIT: 我写了一个较长的一块 https://hackernoon.com/are-interfaces-code-smell-bd19abc266d3#.dvyk5m4ge关于这个问题，详细解释了问题和解决方案。

尽管该用例似乎存在一种设计模式（现在很多人都提到了“标记接口”），但我相信这种做法的使用表明了代码味道（至少在大多数时候）。

正如 @V4Vendetta 发布的，有一个针对此的静态分析规则：http://msdn.microsoft.com/en-us/library/ms182128(v=VS.100).aspx http://msdn.microsoft.com/en-us/library/ms182128(v=VS.100).aspx

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

这是引用的 MSDN 建议：

删除接口或向其中添加成员。如果使用空接口来标记一组类型，请使用自定义属性替换该接口。

这也反映了已发布的维基百科链接的批评部分。

标记接口的一个主要问题是接口定义了用于实现类的契约，并且该契约由所有子类继承。这意味着您不能“取消实现”标记。在给出的示例中，如果您创建一个不想序列化的子类（可能是因为它依赖于瞬态），则必须显式抛出 NotSerializedException（根据 ObjectOutputStream 文档）。