为什么用"I"前缀C#接口名称

这个命名惯例背后的理由是什么？

我没有看到任何好处.额外的前缀只会污染API.

我的想法是内嵌康拉德的响应该相关问题 ; 所选择的答案主要是我在这里要求的.

1> Bart Czernic..：

---

完全相反,命名约定清楚地标识了一个接口.

例如,如果你有:

public class Dog : IPet, IMammal
{
    ....

仅仅是阅读它,我可以放心地假设IPet和IMammal可能是接口.

.NET CLR允许单类继承.所以,如果我有一个基类..我只能从它继承一个类.让我们将IPet接口更改为基类.现在我们的示例变为

public class Dog : Pet, IMammal
{
    ....

我继承Pet类并实现IMammal接口.

如果我们按照你的建议去做并删除了字母"我",我们就有这个:

public class Dog : Pet, Mammal
{
    ....

哪一个是我继承的班级？我正在实施哪个界面？这让人感到困惑吧？(仅供参考.你应该把基类放在第一位,所以你可以争论这一点......但是如果你想要从界面名称前面删除字母I我怀疑你也遵循这种做法)

正如您所看到的那样,命名约定很容易告诉我很多关于我的对象的事情,而不必进一步调查.我可以很容易地看到我继承的内容与我正在实施的内容.

---

为什么我们不用"A"/"C"加上抽象/具体类型的前缀,用"E"加上枚举,用"S"加上结构等等？

---

这说得通.那么,在C#中,Java的"扩展和实现"是如何混合在一起的？

---

具有讽刺意味的是,java实际上是正确的.界面不再以"I"为前缀,但它实际上被认为是BAD练习.请参阅Joshua Bloch撰写的"Effective Java".

---

我遵循你提到的"基类永远第一"的惯例.尽管如此,我不能同意你的说法"命名惯例很容易告诉我很多关于我的对象".例如,区分界面,抽象/具体类,枚举,struts等对API级别没有意义.

---

这没有解决的问题是更为基本的问题,为什么你需要将类型识别为一个接口,而不仅仅是你需要确定它是一个类还是一个结构......或者它是抽象的还是不......,或者它是否包含实例成员或仅包含静态成员......我认为我们这样做了,但我不确定最佳答案是什么......

---

这是最好的答案,但实际的原因(根据Krzysztof Cwalina),"I"用于"历史原因"和(根据Brad Abrams),它清楚地认识到COM(和Java)的影响在.NET Framework上,决定推进它是因为.NET Framework的早期采用者已经熟悉了COM`.(有关更详细的报价,请参阅此答案.http://stackoverflow.com/questions/222457/are-there-established-alternatives-to-isomething-isomethingable-for-interfaces/222500#222500)

2> Charles Bret..：

---

我也喜欢它,因为我可以把它读作"我动词行为",如"ICanSave"或"IDoDoubleEntry"等......

---

IEnumerable - 听起来像一个穴居人说话.UGG.

---

哈哈,肯定是对IDoDoubleEntry的支持.

---

我总觉得我的界面名听起来有点像lolcats."ICanHasCheeseburger"

---

也许前缀应该是'我'.

3> Sean Reilly..：

---

我认为IInterface命名约定很愚蠢.这是匈牙利符号的一个例子,我赞同鄙视匈牙利符号的思想学派.如果您的接口只有一个具有相同名称的实现,请考虑这可能是代码异味.

但是,我仍然使用它,因为在这种情况下,Microsoft推荐使用IInterface,并且"标准优于更好".

---

我也不是匈牙利人的粉丝,但我最近遇到了这篇古老的Joel文章,这篇文章解释了它的起源以及它是如何被广泛误解的 - 至少我现在可以看到它背后的原因!http://www.joelonsoftware.com/articles/Wrong.html

4> 小智..：

---

为什么这不是语法高亮而不是匈牙利符号的功能？如果区分类和接口如此重要,那么为什么IDE不会仅仅使用引用接口的标识符.我讨厌在字段之前放" "或"m ",在课前放" C"等等.更糟糕的是,它鼓励程序员编写非常糟糕的API,例如:

public class List : IList

而不是更合理:

public class LinkedList : List
public class ArrayList : List
public class HashList : List

即使是.NET普通类作者也陷入了这个陷阱.类名永远不应该是只删除了"I"的接口的名称.类名应始终告诉用户类与接口的其他可能实现的不同之处.因为这个原因我投票放弃了愚蠢的"我".

此外,当我使用intellisense时,我想按功能区域分组,而不是它是一个类还是接口.我从不认为,"我需要一个界面,而不是一个类." 我一直认为,"我需要做X的东西".

---

我很高兴我不是唯一一个以这种方式看待它的人.看起来我确实是少数.4年后,我仍然惊讶于有多少读者发誓"这使得识别界面变得容易"并完全忽略了这一点.

---

在设计具有可扩展性的接口时,这是一个非常好的观点,但抽象接口(C#和Java)的另一个用例纯粹是为了解耦以允许模拟依赖关系,其中没有其他具体的接口实现.明确地'为'设计'.所以`MyReallySpecificBusinessComponent`和`IMyReallySpecificBusinessComponent`会好的.但绝对不是`List`.

5> Tim Jarvis..：

---

实际上我发现避免命名冲突很有用,例如我可能会创建一个名为Fred的具体类来实现IFred

---

使用有意义/有用的名称可以避免命名冲突.例如弗雷德扩展人,实现生活,呼吸和其他能力.没有更多的上下文我不能肯定地说,但如果Fred是一个域/模型对象,拥有它的接口可能是多余的.

6> MarkDav.is..：

---

我一直认为将动词用于行为界面很有趣。这与使用名词的类命名约定有所不同，但是它允许类“讲”其行为。

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

我认为实际上这是一个理智的惯例。