对TypeScript的接口和类编码指南感到困惑

Question

我通读了TypeScript Coding guidelines

我觉得这句话很令人费解：

  

不要使用“I”作为接口名称的前缀

我的意思是，没有“我”前缀

，这样的事情就没有多大意义

class Engine implements IEngine

我错过了一些明显的东西吗？

我不太明白的另一件事是：

  

类

     

为了保持一致性，请不要在核心编译器管道中使用类。使用   相反，函数闭包。

这是否表明我根本不应该使用类？

希望有人可以为我清理它：）

Answer 1

当团队/公司发布框架/编译器/工具集时，他们已经拥有一些经验，一套最佳实践。他们将其作为准则分享。指南是建议。如果你不喜欢任何你可以忽视他们。 编译器仍然会编译您的代码。 虽然when in Rome...

这是我的愿景，为什么TypeScript团队建议不要I - 为接口添加前缀。

原因＃1 Hungarian notation已过去的时间

来自I的主要参数 - 前缀为接口的支持者是前缀有助于立即grokking（peeking）type是否是接口。声明前缀有助于立即grokking（偷看）是对Hungarian notation的吸引力。接口名称为I前缀，类为C，抽象类为A，字符串变量为s，const变量为c，i对于整数变量。我同意这样的名称修饰可以为您提供类型信息，而无需将鼠标悬停在标识符上或通过热键导航到类型定义。 Hungarian notation缺点和下面提到的其他原因超过了这个微小的好处。匈牙利符号在当代框架中没有使用。由于历史原因（COM），C＃具有I前缀（并且这是C＃中唯一的前缀）。回想起来，.NET架构师之一（Brad Abrams）认为它会更好not using I prefix。 TypeScript是COM-legacy-free，因此没有I - 前缀接口规则。

原因＃2 I - 前缀违反封装原则

让我们假设你得到一些黑盒子。您将获得一些类型引用，允许您与该框进行交互。你不应该关心它是一个接口还是一个类。你只需使用它的界面部分。要求知道它是什么（接口，特定实现或抽象类）是违反封装的。

示例：我们假设您需要在代码中修复API Design Myth: Interface as Contract，例如删除ICar接口并改为使用Car基类。然后，您需要在所有消费者中执行此类替换。 I - 前缀导致消费者对黑盒实现细节的隐式依赖。

原因＃3防止错误命名

开发人员懒得正确思考名称。命名是Two Hard Things in Computer Science之一。当开发人员需要提取接口时，只需将字母I添加到类名中即可获得接口名称。禁用接口的I前缀会迫使开发人员绞尽脑汁为界面选择合适的名称。选择的名称不仅应在前缀上有所不同，还应强调意图差异。

抽象案例：您应该不不定义ICar接口和关联的Car类。 Car是一个抽象，它应该是用于合同的抽象。实现应该具有描述性的，独特的名称，例如SportsCar, SuvCar, HollowCar。

很好的例子：WpfeServerAutosuggestManager implements AutosuggestManager，FileBasedAutosuggestManager implements AutosuggestManager。

错误示例：AutosuggestManager implements IAutosuggestManager。

原因＃4正确选择的名称针对API Design Myth: Interface as Contract接种疫苗。

在我的实践中，我遇到了很多人，他们在一个具有Car implements ICar命名方案的独立界面中轻率地复制了一个类的接口部分。在单独的接口类型中复制类的接口部分并不会将其神奇地转换为抽象。您仍将获得具体的实现，但具有重复的接口部分。如果您的抽象不太好，那么复制界面部分无论如何都不会改进它。提取抽象是一项艰苦的工作。

Answer 2

关于您引用的链接的说明：

  

这是有关TypeScript代码样式的文档，而不是有关如何实现项目的样式指南。

如果使用I前缀对您和您的团队有意义，请使用它（我这样做）。

如果没有，那么SomeThing（接口）与SomeThingImpl（实现）的Java风格可能会使用它。

Answer 3

作为接口的类型是实现细节。实现细节应隐藏在API：s中。这就是为什么您应该避免使用I。

您应避免使用机器人prefix 和 suffix。这些都是错误的：

• ICar
• CarInterface

您应该做的是在API中显示一个漂亮的名称，并在实现中隐藏实现细节。这就是为什么我提议：

• Car-API中公开的接口。
• CarImpl-对使用者隐藏的该API的实现。

Answer 4

我发现 @ stanislav-berkov 对于OP的问题是一个很好的答案。我只愿分享我的2美分，最后要取决于您的团队/部门/公司/一切才能达成共识，并制定自己的规则/指南以供遵循。

只要有可能，就遵循标准和/或约定是一种很好的做法，它使事情更容易理解。另一方面，我想认为我们仍然可以自由选择编写代码的方式。

从情感方面考虑，我们编写代码的方式或我们的编码风格反映了我们的个性，在某些情况下甚至反映了我们的心情。这使我们成为人类，而不仅仅是遵循规则的机器。 我相信编码可以是一种技巧，而不仅仅是一个工业化的过程。

Answer 5

我个人非常喜欢通过添加 -able 后缀将名词变成形容词的想法。听起来很不恰当，但我喜欢它！

interface Walletable {
  inPocket:boolean
  cash:number
}


export class Wallet implements Walletable {
  //...
}

}

Answer 6

TypeScript's handbook全部说明。只要注意那里的例子就可以了。 <3