【问题讨论】：
标签： c# naming-conventions interface
完全相反，命名约定清楚地标识了一个接口。
例如，如果您有：
public class Dog : IPet, IMammal
{
....
仅仅通过阅读，我可以有把握地假设 IPet 和 IMammal 可能是接口。
.NET CLR 允许单类继承。所以，如果我有一个基类..我只能从它继承一个类。让我们将 IPet 接口更改为基类。我们的示例现在变为
public class Dog : Pet, IMammal
{
....
我从 Pet 类继承并实现 IMammal 接口。
如果我们按照您的建议进行操作并删除了字母“I”，我们将得到：
public class Dog : Pet, Mammal
{
....
我从哪个类继承？我正在实现哪个接口？它会变得混乱吗？ （仅供参考..您应该始终将基类放在首位，因此您可以争论这一点...但是如果您主张从接口名称前缀中删除字母 I，我怀疑您是否也遵循这种做法）
正如您所见，命名约定很容易告诉我很多关于我的对象的信息，而无需我进一步调查。我可以很容易地看到我正在继承什么与我正在实施什么。
【讨论】：
我也喜欢它，因为我可以将它读作“Iverb-behavior”，如“ICanSave”或“IDoDoubleEntry”等......
【讨论】：
ICanSave 应该是 ISaveble。
IClonable、IDisposable 和 IComparable 而不是 ICanClone、ICanDispose 或 ICanCompare。跨度>
我认为 IInterface 命名约定很愚蠢。这是匈牙利符号的一个例子，我赞同鄙视匈牙利符号的思想流派。如果您的接口只有一个同名实现，请考虑这可能是代码异味。
不过，我还是用它，因为在这种情况下，IInterface 是微软推荐的，“标准胜于优”。
【讨论】：
为什么这不是句法突出显示而不是匈牙利符号的功能？如果区分类和接口非常重要，为什么 IDE 不将引用接口的标识符用斜体表示。我讨厌在字段前放置“”或“m”，在类前放置“C”等。更糟糕的是，它鼓励程序员编写非常糟糕的 API，例如：
public class List : IList
而不是更合理的：
public class LinkedList : List
public class ArrayList : List
public class HashList : List
即使是 .NET 通用类的作者也落入了这个陷阱。类名永远不应该是只删除“I”的接口名称。类名应始终告诉用户该类与接口的其他可能实现有何不同。仅出于这个原因，我投票赞成放弃愚蠢的“我”。
另外，当我使用智能感知时，我想按功能区域对事物进行分组，而不是按类或接口进行分组。我从来没有想过，“我需要一个接口，而不是一个类。”我总是想，“我需要做 X 的东西”。
【讨论】：
MyReallySpecificBusinessComponent 和IMyReallySpecificBusinessComponent 就可以了。但绝对不是List。
实际上我发现避免命名冲突很有用，例如，我可能会创建一个名为 Fred 的具体类来实现 IFred
【讨论】：
我一直认为将动词用于行为界面很有趣。这与使用名词的类命名约定背道而驰，但它允许类“说出”它的行为。
class Dog: IBark
这对于像 WCF 接口这样的结构化接口并不适用，但我们不需要一直玩得开心。
要回答您的问题，请将I 视为“实现”所以...
class DogDataService : Dog, IDataService
这个服务类继承自Dog并实现IDataService
我还没有真正回答你的问题，但I 很有用，因为你会在命名空间、类和接口之间遇到命名冲突。
namespace DataService
interface DataService
class DataService: DataService
所以我们结束了
namespace DataServices
interface IDataService
class DataService : IDataService
我认为实际上，这是一个理智的约定。
【讨论】：
如果您考虑两个“最佳实践格言”
清晰为王
和
噪音不好
它们之间存在冲突。问题是：什么时候清晰变成噪音？
对我来说，写Person person = new PersonImpl() 比写IPerson person = new Person() 更嘈杂（但同样清晰）。
【讨论】：
要么就是这样，要么在接口的实现中添加“Impl”（啊）。我对“我”没有意见，它是对接口的最简单直接的命名。
【讨论】：
“I”约定似乎是一个与今天无关的旧约定。当前的代码编辑器提供了有关您正在使用的类型的大量见解，因此认为更容易识别接口就像要求命名空间以“N”为前缀，因为您想确保不会混淆它一个具体的类（带有“C”的前缀？）。
约定并不意味着它是一个好的约定。有时，只是因为人们开始使用它......
以 C# 文档生成器为例：它不关心它...如果您的界面没有以“I”为前缀，您仍然会在文档的界面部分看到您的界面。您真的认为在文档的接口部分中为所有接口添加前缀“I”是相关信息并帮助您更好地识别接口吗？
【讨论】：
需要区分接口和类实际上表明存在设计缺陷。在设计良好的应用程序中，它总是很清楚。一个子类应该始终是一个专业化，并且类只能专注于一个学科，不能更多。
一个类应该有一个存在的理由。永远不应要求将次要角色放在基类中。例如：
public class XmlConfigurationFile : ConfigurationFile, IDisposable
{
}
public class YamlConfigurationFile : ConfigurationFile, IDisposable
{
}
第一个是Xml专用的配置文件，第二个是Yaml专用的配置文件。这些也是一次性的，但这并不重要。由于处理过程不同，您没有创建这两个类。
对比一下：
public class XmlConfigurationFile : IDisposable, ConfigurationFile
{
}
这将告诉您 XmlConfigurationFile 的主要目的是它是一次性的。您可以将其用作表示配置文件的一种方式，这很好，但只是次要的。
当您创建具有多种存在原因的类时，问题就开始了：
public class MyConfigurationFile : XmlConfigurationFile, YamlConfigurationFile
{
}
即使 XmlConfigurationFile 和 YamlConfigurationFile 本来是接口，它仍然表明设计不好。你的配置文件怎么能同时是Xml和Yaml呢？
如果您仔细阅读给出的示例（此处和其他地方），人们总是很难找到 I 前缀何时重要的好示例。这里的答案之一是：
public class Dog : Pet, Mammal
{
}
这就是这个类在一个关于宠物的应用程序中的样子。狗的主要目的是成为专门的宠物，可以做与宠物相关的事情，而不是哺乳动物。
public class Dog : Mammal, Pet
{
}
这是同一类在有关动物分类的应用程序中的外观。很高兴知道狗是宠物，但它的主要目的是成为一种专门的哺乳动物，可以做与哺乳动物相关的事情。
我认为您的课程应该告诉您有关应用程序架构和领域的正确故事。要求接口以“I”为前缀是一项技术要求，并不能帮助您更好地讲述应用程序的故事。
一旦您开始编写小型、专用、单一用途的类，了解它是实现还是扩展的需求将自动消失。
【讨论】：
它使它很容易被识别为一个接口。
【讨论】：
命名约定的好处是在您使用对象之前告诉您一些有关该对象的信息。命名约定已被广泛使用多年，一直追溯到 fortran 坚持整数值被限制（如果我没记错的话）为变量名称，如“i”和“j”。
匈牙利符号将命名约定提升到了一个全新的丑陋水平，它描述了变量类型，无论它是否是指针等。我们中的许多人接触过大量使用匈牙利符号的代码后都会出现紧张的抽搐和口吃。
在接口名称前加上 I 是一种影响相对较小、无害的识别对象的方法。
【讨论】：
TL;DR - 从 class Foo 中提取 interface IFoo 在 SOLID 解耦中很常见，尤其是用于单元测试目的
对我来说，类 Foo 实现接口 IFoo 的双重约定（特别是如果两者都在同一个程序集中）传达了一个特定的意图：
Foo 应该始终是间接的，通过相应的 IFoo 接口（并且可能通过 IoC 容器注入）IFoo 的初始设计是一个专有的、不可重用的接口，专门允许依赖于Foo 的类在单元测试期间模拟这种依赖关系。IFoo 接口的设计中推断出任何额外的智能IFoo 的多个具体实现类，则需要将适当的接口隔离设计改进到层次结构中。基本原理
为了能够模拟或存根一个类，单元测试中广泛接受的最佳实践是仅通过接口解耦类之间的依赖关系。这种接口解耦也将在其他情况下 never had a design requirement for polymorphicism 的类上进行（即，如果不需要单元测试，则只会存在一个这样的实现）。
因此，这些接口（例如Interface Segregation Principal of SOLID）的重构和重用并不经常应用于此类“可模拟”接口——公共方法、属性和事件之间通常存在 1:1 的相关性一个“可模拟”类 (Foo) 及其解耦接口 IFoo（类似于 COM 时代的 automatic interfaces in VB）。
VS 和 Resharper 等工具可以轻松地将此类公共符号从类中提取到单独的接口中，作为事后的想法。
此外，如果我们考虑到像 Moq 这样的 Mocking 框架允许 definition of implementations of the interface on-the-fly，我们不必浪费精力来命名具体的测试双重实现类。
【讨论】：
这只是一个命名约定，所以每个人都会知道它是接口还是其他东西，它不是强制性的，也不是编译器或 IDE 的，但我一生中看到的所有接口都以字母 I 开头
【讨论】：
我似乎是匈牙利符号的传统约定。 Interface Naming Guidelines 表示“在接口名称前加上字母 I，表示该类型是一个接口。” Framework Design Guidelines 还说“DO 用字母 I 作为接口名称的前缀，表示该类型是一个接口。”
这只是一个编码约定，因此很难确定好坏。 重要的是一致性。
【讨论】：
首先我认为前缀 I then description 是错误的，因为这意味着实现可以有一个更短的名称。 IList (intf) -> 列表。这是一种反模式，因为我们都知道我们应该在创建时使用 intf 并且可能只使用具体类型。不要激怒我，这是一个概括，但前提是 intf 很少 impl 。实现名称应该描述它如何实现 intf 或它在做什么。想想intf List，LinkedList，它使用链表实现List。谁在乎它是否更长，因为我们大部分时间都应该使用 List 。如果我们有一个实现许多 intf 的类，我们可能不应该包含所有 intf 作为类的真正目的的影子。在没有 intf 的情况下删除的东西是有意义的。例如，人们用我的名字叫我而不是人、兄弟、开发人员等是最好的最具描述性的名字。我想如果一个类是一个简单的 intf 然后调用它 Default Intf 这使得它在 ious 这是 Intf 的默认实现。 类的名称最终应该是人类可读的，并且几乎是描述其目的的简短短语。前缀代码等并不是很好，因为我们用文字而不是代码进行交流。计算机并不关心类的名称，所以剩下的就是我们为事物命名，以便这些名称对我们和我们的同事有所帮助。
【讨论】：
最有可能让它在智能感知中易于识别，因为所有接口都会聚集在一起。类似于我为所有 UI 控件添加 btn、tb、lb 前缀的方式。当智能感知启动时，所有内容都聚集在一个简单的组中。
【讨论】：
有了关于命名约定的所有论点，并为变量和方法赋予正确的名称，这些变量和方法实际上描述了它们的作用……为什么不直接命名你的接口（例如 PetInterface、PlayerInterface 等）并取消前缀“我”都在一起。所以你必须输入额外的 9 个字母，至少“I”被删除，我们知道它不是一个类，因为它说“接口”。
【讨论】：