界面-不好的做法？可能重复：标记界面的目的是什么？创建一个完全空的接口是不好的做法，例如：publicinterfaceISomething{}在某些情况下，我希望某些对象的处理方式与其他对象不同，但我不需要任何新行为。我个人认为空接口不是一件好事。接口用于描述行为契约。一个空接口不描述任何行为——你没有在这里定义任何类型的契约。InterfaceDesignGuidelines明确指出：避免使用标记接口（没有成员的接口）。自定义属性提供了一种标记类型的方法。有关自定义属性的更多信息，请参阅编写自定义属性。当您可以将检查属性推迟到代码执行时，自定义属性是首选。如果您的方案需要编译时检查，则不能遵循此指南。您是否考虑过使用属性而不是接口？这通常是我的方法。诚然，测试属性是否存在比对象是否实现接口要难一些，但总体感觉更合适。我会说属性更好，但是.Net框架中有空接口的示例（例如INamingContainer-http://msdn.microsoft.com/en-us/library/system.web.ui.inamingcontainer.aspx).我一直想知道为什么这样做-有人知道吗？我同意大家的看法。我想如果给我代码来维护并看到一个没有属性或方法的接口的类，我会很困惑。在我最近一直在处理的asp.netmvc应用程序中，我有一个核心操作（跟踪代码），我想对几乎每个请求（但不是说ajax请求或管理页面）执行。我将动作添加到基本控制器并在ExecuteCore方法中执行它。对于我不希望它运行的少数情况，我在派生控制器中设置了一个标志以不运行它。这不像属性那样简洁优雅，但实现起来要简单得多。当然，如果您想为所有派生类创建通用操作，这将无济于事。但在这种情况下，对象必须有一些共同点（如公共属性），这意味着接口不会为空。在我看来，实现一个标记接口和附加一个没有参数的属性只是语法上的不同，但前者更直接地用于运行时类型信息。我个人并不准备制定一个绝对不能使用标记接口的硬性规定，但我可以看到，如果它们不仅仅用于“标记”，则可能会导致失败——在这种情况下，属性可能更合适。也就是说，如果我第一次遇到一个空接口（我肯定记得Java大约2000年），我第一次遇到一个属性（C#web服务）——我能够推断出一个，但另一个迫使我进入学习模式……我不喜欢，但我并不反对。我经常为泛型类型创建一个基类，这样我就可以包含一组泛型项。接口可能是一种更简洁的方法，但我通常会在基类中找到一些东西，因此接口解决方案在这里不起作用。我想您可以将其视为抽象基类吗？以上是C#学习教程：没有任何成员的接口——不好的做法？如果所有分享的内容对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
