命名问题：“ Isomething”是否应重命名为“ Something”？[关闭]

Bob叔叔在“ 干净代码”中有关名称的章节中建议您避免使用名称编码，主要是关于匈牙利表示法。他还特别提到I从接口中删除前缀，但没有显示此示例。

让我们假设以下内容：

• 接口的使用主要是通过依赖注入实现可测试性
• 在许多情况下，这导致与单个实施者具有单个接口

因此，例如，这两个应命名为什么？Parser和ConcreteParser？Parser和ParserImplementation？

public interface IParser {
    string Parse(string content);
    string Parse(FileInfo path);
}

public class Parser : IParser {
     // Implementations
}

还是在这样的单一实现案例中忽略该建议？

尽管包括“鲍勃叔叔”在内的许多人都建议不要将I其用作接口的前缀，但这是C＃的一种既定传统。一般而言，应避免这种情况。但是，如果您正在编写C＃，则确实应该遵循该语言的约定并使用它。不这样做将与其他熟悉C＃并试图读取您的代码的人产生巨大的困惑。

接口是重要的逻辑概念，因此，接口应带有通用名称。所以，我宁愿有

interface Something
class DefaultSomething : Something
class MockSomething : Something

比

interface ISomething
class Something : ISomething
class MockSomething : ISomething

后者有几个问题：

1. 某物只是ISomething的一种实现，但它是具有通用名称的那个，好像它在某种程度上很特殊。
2. MockSomething似乎源于Something，但实现了ISomething。也许应该将其命名为MockISomething，但我从未在野外看到它。
3. 重构比较困难。如果Something现在是一个类，而您以后才发现必须引入一个接口，则该接口应命名为相同的接口，因为无论类型是具体类，抽象类还是接口，该接口对客户端都是透明的。ISomething打破了这一点。

这不仅仅是关于命名约定。C＃不支持多重继承，因此在从基类继承并实现一个或多个接口的情况下，这种匈牙利符号的旧用法虽然有用，但仍具有很小的好处。所以这...

class Foo : BarB, IBarA
{
    // Better...
}

...比这更好...

class Foo : BarB, BarA
{
    // Dafuq?
}

海事组织

不不不。

命名约定不是Bob叔叔的狂热粉丝的功能。它们不是c＃或其他语言的功能。

它们是您的代码库的功能。在您的商店范围内要小得多。换句话说，代码库中的第一个设置了标准。

只有这样，您才能决定。之后，请保持一致。如果某人开始变得前后矛盾，请拿走他们的nerf枪，让他们更新文档，直到他们悔改为止。

在阅读新的代码库时I，无论哪种语言，我都看不到前缀，这很好。如果我在每个界面上都看到一个，那很好。如果我有时看到一个，有人会付钱。

如果您发现自己处于为代码库设置此先例的稀缺环境中，请您考虑一下：

作为客户班，我保留不给我在说什么的权利。我所需要的只是一个名称和可以针对该名称调用的内容列表。除非我这样说，否则这些可能不会改变。我拥有那一部分。我正在谈论的内容（不是界面）不是我的部门。

如果您I以这个名字偷偷摸摸，客户将不在乎。如果没有I，则客户端不在乎。它在说什么可能是具体的。可能不会。由于new无论哪种方式都没有调用它，因此没有区别。作为客户，我不知道。我不想知道

现在，即使是在Java中，作为代码猴子查看该代码，这也可能很重要。毕竟，如果我必须将实现更改为接口，则可以在不通知客户端的情况下进行操作。如果没有I传统，我什至无法重命名。这可能是个问题，因为现在即使源不关心二进制文件，我们也必须重新编译客户端。如果您从未更改过名字，很容易错过。

也许这对您来说不是问题。也许不吧。如果是这样，那就是一个值得照顾的好理由。但是对于喜欢台式玩具的人来说，不要说我们应该盲目地这样做，因为这是某些语言的处理方式。要么有该死的正当理由，要么不在乎。

这不是要永远与它共存。除非您准备好在所有地方解决“问题”，否则不要给我关于不符合您的特定心态的代码库的废话。除非您有充分的理由，否则我不应该走最小程度的抵抗统一的道路，也不要来找我宣扬整合。我有更好的事情要做。

Java和C＃之间存在一个微小的差异，在这里是相关的。在Java中，默认情况下，每个成员都是虚拟的。在C＃中，默认情况下每个成员都是密封的-接口成员除外。

与此相关的假设会影响准则-在Java中，根据Liskov的“替代原则” [1]，每个公共类型都应视为非最终类型。如果只有一个实现，则将其命名为class Parser。如果发现需要多个实现，则只需将类更改为具有相同名称的接口，然后将具体实现重命名为描述性名称。

在C＃中，主要假设是当您获得一个类（名称不以开头I）时，这就是您想要的类。请注意，这远远不能达到100％的准确度-一个典型的反例就是类似的类Stream（它确实应该是一个接口或几个接口），并且每个人都有自己的使用其他语言的指南和背景。还有其他例外，例如使用相当广泛的Base后缀来表示抽象类-就像具有接口一样，您知道类型应该是多态的。

还有一个很好的可用性功能，它为与该接口相关的功能保留了非I前缀的名称，而不必诉诸使该接口成为抽象类（由于C＃中缺少类多重继承，这会造成伤害）。这被LINQ所普及，它IEnumerable<T>用作接口以及Enumerable适用于该接口的方法的存储库。在Java中，接口也可以包含方法实现，这是不必要的。

最终，该I前缀在C＃世界中广泛使用，并在.NET世界中得到扩展（由于到目前为止，大多数.NET代码都是用C＃编写的，因此对于大多数公共接口，都应遵循C＃准则）。这意味着您几乎可以肯定会使用遵循该符号的库和代码，并且采用这种传统来防止不必要的混乱是很有意义的-就像省略前缀不会使您的代码变得更好:)

我认为鲍勃叔叔的推理是这样的：

IBanana是香蕉的抽象概念。如果有任何实现类没有比更好的名称Banana，那么抽象是完全没有意义的，您应该删除接口并仅使用一个类。如果有一个更好的名称（例如LongBanana或AppleBanana），则没有理由不使用它Banana作为接口的名称。因此，使用I前缀表示您有一个无用的抽象，这使代码更难理解，没有任何好处。而且由于严格的OOP总是让您针对接口进行编码，因此唯一看不到I类型前缀的地方就是构造函数-毫无意义。

如果将其应用于示例IParser接口，则可以清楚地看到抽象完全在“无意义”的范围内。无论是有一些具体的事情有关的具体实现解析器（例如JsonParser，XmlParser...），或者你应该只使用一个类。没有“默认实现”这样的东西（尽管在某些环境中，这确实有意义-尤其是COM），或者有特定的实现，或者您想要“默认值”的抽象类或扩展方法。但是，在C＃中，除非您的代码库已经省略了I-prefix，否则请保留它。每当您看到类似的代码时class Something: ISomething，都需要在脑子里记一下-这意味着有人不太擅长遵循YAGNI并构建合理的抽象。

[1]-从技术上讲，这在Liskov的论文中没有特别提及，但这是原始OOP论文的基础之一，在我阅读Liskov时，她没有对此提出质疑。在一种不太严格的解释中（大多数OOP语言采用的一种解释），这意味着使用打算用于替代（即非最终/密封）的公共类型的任何代码都必须与该类型的任何符合实现一起工作。

因此，例如，这两个应命名为什么？解析器和ConcreteParser？解析器和ParserImplementation？

在理想的世界中，您不应在名字前面加上简写形式（“ I ...”），而应让名字表达一个概念。

我在某处读到（无法找到它）该ISomething约定使您在需要“ Dollar”类时可以定义“ IDollar”概念，但正确的解决方案是简单地称为“ Currency”的概念。

换句话说，约定使命名事物的难易程度变得容易，而容易犯错是微妙的。

在现实世界中，您的代码的客户端（可能只是“未来的您”）需要能够稍后阅读并尽可能快地（或不费吹灰之力）熟悉它（给客户端他们期望得到的代码）。

ISomething约定引入了临时名称/错误名称。话虽如此，但实际上并不是真正的*），除非编写代码所使用的约定和实践不再实际；如果约定说“使用ISomething”，那么最好使用它，使其与其他开发人员保持一致（并更好地工作）。

*）我可以这样说，因为“残酷”不是一个确切的概念：)

就像其他答案提到的那样，在I.NET框架的编码准则中会以前缀前缀您的接口名称。因为与C＃和VB.NET中的通用接口相比，具体类更经常与之交互，所以它们在命名方案中是一流的，因此应具有最简单的名称-因此，IParser用于接口和Parser默认实现。

但是在Java和类似语言的情况下，首选接口而不是具体的类，Bob叔叔是对的，因为I应该删除，而接口应该使用最简单的名称-例如Parser对于您的解析器接口。但是，而不是基于角色的名字一样ParserDefault，该类应该有一个描述名称如何解析器实现：

public interface Parser{
}

public class RegexParser implements Parser {
    // parses using regular expressions
}

public class RecursiveParser implements Parser {
    // parses using a recursive call structure
}

public class MockParser implements Parser {
    // BSes the parsing methods so you can get your tests working
}

这是，例如，如何Set<T>，HashSet<T>以及TreeSet<T>命名。

您是对的，因为我的I =接口约定违反了（新）规则

在过去，您会为所有内容添加类型为intCounter boolFlag等的前缀。

如果要命名时不带前缀，也要避免使用“ ConcreteParser”，则可以使用名称空间

namespace myapp.Interfaces
{
    public interface Parser {...
}


namespace myapp.Parsers
{
    public class Parser : myapp.Interfaces.Parser {...
}