接口命名约定 [英] Interface naming convention

问题描述

这当然是一个主观的事情，但我认为在接口名称前加上I"没有任何积极意义.对我来说，Thing 实际上总是比 IThing 更具可读性.

This is a subjective thing of course, but I don't see anything positive in prefixing interface names with an 'I'. To me, Thing is practically always more readable than IThing.

我的问题是，为什么会存在这个约定?当然，它可以更容易地将接口与其他类型区分开来.但是，这种争论是否会延伸到保留现在受到广泛谴责的匈牙利符号?

My question is, why does this convention exist then? Sure, it makes it easier to tell interfaces from other types. But wouldn't that argument extend to retaining the Hungarian notation, which is now widely censured?

你对那个尴尬的我"有什么看法?或者，更重要的是，微软会是什么?

What's your argument for that awkward 'I'? Or, more importantly, what could be Microsoft's?

推荐答案

约定俗成(以及对它们的批评)都有其背后的原因，所以让我们分析一下约定俗成背后的一些原因

Conventions (and criticism against them) all have a reason behind them, so let's run down some reasons behind conventions

• 接口以 I 为前缀，以区分接口类型和实现 - 例如，如上所述，需要一种简单的方法来区分 Thing 和它的接口 IThing 因此约定用于此目的.

• Interfaces are prefixed as I to differentiate interface types from implementations - e.g., as mentioned above there needs to be an easy way to distinguish between Thing and its interface IThing so the convention serves to this end.

接口以 I 为前缀，以区别于抽象类 - 当您看到以下代码时会产生歧义:

Interfaces are prefixed I to differentiate it from abstract classes - There is ambiguity when you see the following code:

公共课苹果:水果

如果没有这个约定，人们就不会知道 Apple 是继承自另一个名为 Fruit 的类，还是一个名为 Fruit 的接口的实现，而 IFruit 会使这一点显而易见:

Without the convention one wouldn't know if Apple was inheriting from another class named Fruit, or if it were an implementation of an interface named Fruit, whereas IFruit will make this obvious:

苹果公开课:IFruit

最小惊喜原则适用.

并非所有匈牙利表示法的使用都受到谴责 - 匈牙利表示法的早期使用表示一个表示对象类型的前缀，然后是变量名，或者有时在之前的下划线变量名称.这对于某些编程环境(想想 Visual Basic 4 - 6)很有用，但随着真正的面向对象编程越来越流行，指定类型变得不切实际和多余.当涉及到智能感知时，这尤其成为问题.

Not all uses of hungarian notation are censured - Early uses of Hungarian notation signified a prefix which indicated the type of the object and then followed by the variable name or sometimes an underscore before the variable name. This was, for certain programming environments (think Visual Basic 4 - 6) useful but as true object-oriented programming grew in popularity it became impractical and redundant to specify the type. This became especially issue when it came to intellisense.

今天的匈牙利符号可以用来区分 UI 元素与实际数据和类似关联的 UI 元素，例如，txtObject 表示文本框，lblObject 表示与那个文本框，而文本框的数据只是Object.

Today hungarian notation is acceptable to distinguish UI elements from actual data and similarly associated UI elements, e.g., txtObject for a textbox, lblObject for the label that is associated with that textbox, while the data for the textbox is simply Object.

我还必须指出，匈牙利表示法的最初用途不是用于指定数据类型(称为系统匈牙利表示法)，而是指定变量名称的语义使用(称为 Apps 匈牙利表示法).在维基百科关于匈牙利符号的条目上阅读更多相关信息.

I also have to point out that the original use of Hungarian notation wasn't for specifying data types (called System Hungarian Notation) but rather, specifying the semantic use of a variable name (called Apps Hungarian Notation). Read more on it on the wikipedia entry on Hungarian Notation.

这篇关于接口命名约定的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！