当前位置:  开发笔记 > 编程语言 > 正文

是否已建立ISomething/ISomethingable接口的替代方案?

如何解决《是否已建立ISomething/ISomethingable接口的替代方案?》经验,为你挑选了3个好方法。

使用I为接口名称添加前缀的.NET标准似乎正在变得普及,并且不再仅限于.NET.我遇到了很多使用这种约定的Java代码(因此,如果Java在C#之前使用它,它就不会让我感到惊讶).Flex也使用它,依此类推.虽然在名字的开头放置一个I有点匈牙利符号,所以我对使用它感到不舒服.

所以问题是,是否存在一种表示Something是接口而不是类的替代方式,无论如何都需要表示它.或者它是否成为一个标准,所以我应该接受它并停止通过建议以不同的方式做出"宗教战争"?



1> Scott Dorman..:

来自框架设计指南书:

表示层次结构根(例如IList)的接口也应使用名词或名词短语.表示能力的界面应使用形容词和形容词短语(例如IComparable,IFormattable).

另外,从界面命名的注释:

KRZYSZTOF CWALINA:使用的少数前缀之一是接口的"I"(如ICollection),但这是出于历史原因.回想起来,我认为使用常规类型名称会更好.在大多数情况下,开发人员并不关心某些东西是接口而不是抽象类.

BRAD ABRAMS:另一方面,接口上的"I"前缀清楚地表明了COM(和Java)对.NET Framework的影响.COM普及,甚至制度化,接口以"I"开头的符号.尽管我们讨论了与这种历史模式的分歧,但我们决定推进这种模式,因为我们的许多用户已经熟悉COM.

JEFFREY RICHTER:就个人而言,我喜欢"I"前缀,我希望我们有更多这样的东西.小的单字符前缀在保持代码简洁和描述性方面有很长的路要走.正如我之前所说,我使用前缀作为我的私有类型字段,因为我觉得这非常有用.

BRENT RECTOR注意:这实际上是匈牙利符号的另一个应用(尽管没有符号在变量名中使用的缺点).

它已经成为一种广泛采用的标准,虽然它是匈牙利语的一种形式,正如布伦特所说的那样,它没有在变量名中使用匈牙利符号的缺点.



2> Jon Skeet..:

说实话,我会接受它.我知道你有点像匈牙利表示法(或者至少滥用相同的表达方式)的意思,但我认为在这种情况下它值得做足够的价值.

随着依赖注入变得流行,我经常发现我最终得到了一个接口和一个生产实现.只需使用I前缀即可轻松区分它们.

一个小数据点:我同时使用Java和C#,我经常发现自己必须检查Java中哪些类型实际上是接口,特别是在集合框架周围..NET就是这么简单.也许它不会打扰其他人,但它困扰我.

来自我的IFoo +1.


@ i3ensays:"文件名旁边"假设你在包浏览器或其他任何东西中查看它.只是*阅读代码*时,我宁愿不采取任何行动.是的,我可以看一切,但我不愿意.这绝对是一个主观的事情,但我喜欢.NET惯例.
@ i3ensays:那是你写*代码的时候.我花了更多的时间*阅读*代码而不是编写它...而且很多时候是在差异视图等而不是IDE.

3> Konrad Rudol..:

作为一个.NET程序员(大多数情况下),我实际上更喜欢抛弃I此处的Java约定,原因很简单:通常,小型重新设计需要从接口更改为抽象基类,反之亦然.如果必须更改名称,则可能需要进行大量不必要的重构.

另一方面,客户端的使用应该是透明的,因此他们不应该关心这种类型的提示.此外,"Thingable"中的"able"后缀应该足以提示.它在Java中运行良好.

/编辑:我想指出,上述推理促使我放弃了I私人项目的前缀.但是,在根据FxCop规则集检查其中一个时,我立即恢复使用I.一致性在这里获胜,尽管愚蠢的一致性是小脑袋的大人物.


@drozzy:嗯,**每个**.NET项目都使用.NET框架API.并使用`I`作为接口前缀.此外,没有真正的项目完全独立于其他项目,项目迟早会变得如此之大以至于需要与其他现有API进行交互.并且每个代码都应该是未来的证明,因为你永远不知道将来这个代码是否会在别处使用,或者需要与外部代码进行交互..NET框架基本上规定了在其他.NET项目中使用的所有基本约定.
推荐阅读
jerry613
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有