接口的打字稿样式指南答案

【问题标题】：Typescript style guide for interfaces接口的打字稿样式指南
【发布时间】：2017-12-01 17:52:46
【问题描述】：

这是一个可能没有一个正确答案的问题，因为我确实意识到编码风格是多种多样的，尤其是在不同的语言之间，例如 javascript 中的驼峰式函数名称与 C# 中的 pascal 大小写方法。我可以接受。

也许我对此担心过度，但我才刚刚开始研究 typescript，非常喜欢它的外观并计划将它与 Angular2 一起使用，并希望建立一个好的样式指南。

我真正不明白的是第 2 点 here，不要使用 I 前缀作为接口。在此之前，我认为这几乎是普遍的。我有一个类 Car，如果接口只是在前面添加一个 I，那么一个自然名称...... ICar。只要你看到 I 前缀，你就知道你有一个接口。

我想遵循任何建议的做法，但这一个我真的不知道为什么要去。

没有人知道为什么，我认为几乎是普遍的约定，在这里被劝阻吗？我知道你可以使用任何你喜欢的约定，只是想知道在 Typescript 中不使用这种通用约定是否有某种原因。

提前感谢您的任何意见/信息！

【问题讨论】：

标签： typescript angular

【解决方案1】：

I 作为前缀在某些时候对于 Java 和 C#（可能还有其他）很大，但我认为这仍然不是一个好主意，但是如何改变大多数开发人员使用的东西和现有的代码库。

它类似于普遍认为是不好的做法的匈牙利符号。只要给它一个有意义的名字。如果您有不同类型的Cars，那么将Car 设置为通用接口和class FancyCar implements Car 更自然。前缀之类的东西只会阻止人们思考他们真正想要表达的东西。另见http://c2.com/cgi/wiki?IntentionRevealingNames

还有像 Dart 这样的语言（可能还有很多我不知道的语言）在 interface 和 class 之间没有如此明显的区别。在 Dart 中，你可以实现任何类。类的接口只是充当interface。

更新

我并不是说命名很容易。事实上，我认为它是软件开发中最困难的部分，或者至少是最困难的部分。只是“精英”的普遍共识是，出于技术原因的前缀并不是最好的方法。这并不意味着存在只有优点而没有缺点的替代方案。在这种情况下，似乎使用了UserService、UserServiceImpl、MockUserService 之类的命名。这样，在您的代码的大部分部分中，最自然的方式 UserService 被使用，并且仅在 prividers 中派生。否则，如上所述，一致性更为重要。如果某些样式在您使用的语言中更常见，我建议您也可以在您的代码中使用它。

【讨论】：

感谢您的反馈。当您出于多态原因使用接口时，FancyCar implements Car 等参数有效，但经常使用，例如比如说一个 Angular 服务，会有一个实例，例如FileSystemService，UserService，我们可以将它们全部实现到一个接口中，所以我们总是将接口而不是具体类注入到服务消费者中。这样就可以轻松地将类模拟到接口等。这意味着您需要为每个服务的接口考虑一个替代名称，而不是一个简单的前缀（例如IFileSystemService、IUserService）。
再次感谢您的 cmets。我想我们可以使用后缀而不是前缀，但到最后不是一样吗？我想我们也会使用FileSystemServiceInterface。我已经看过很多在接口中带有“I”的教程（由 js 词中备受推崇的权威人士），这就是为什么我最初认为它会遵循与基于 lclass 的语言（如 C#）类似的约定（它使用它的地方）时间），以及为什么当我后来看到风格指南时感到惊讶，它如此明确地针对这一约定。值得深思。
是的，所以把它转过来并“标记”类而不是接口。旧的 MS C++ MFC 样式使用“C”前缀作为类（例如 CFileSystemService），以及可怕的完整匈牙利符号（这当然很糟糕）。都值得深思。也许“C”前缀可能不是那么糟糕，但不要再看到它在任何地方使用，只是感觉老派。随着更多 Angular 2 内容的可用，将密切关注更多示例，其中将有许多组件/服务示例以及单元测试模拟。看看将采用哪些约定很有趣。
值得注意的是，截至 2017 年 3 月，微软仍建议在 C# 中使用“I”前缀：docs.microsoft.com/en-us/dotnet/standard/design-guidelines/…
@TravisWilson 回想起来，一位 .NET 架构师 (Brad Abrams) 认为不使用 I 前缀会更好。 blogs.msdn.microsoft.com/brada/2004/02/03/… TypeScript 没有 COM-legacy-free，因此它没有 I-prefix-for-interface 规则。

【解决方案2】：

在这里Confused about the Interface and Class coding guidelines for TypeScript提出了类似的问题

我的回答：https://stackoverflow.com/a/41967120/586609

原因：

匈牙利符号的时代已经过去了
I-前缀违反封装原则
防止命名不当
正确选择的名称可以帮助您对抗 API 设计神话：接口即契约。

【讨论】：

【解决方案3】：

没有理由做或不做某事，只是因为它是惯用的。如果您希望您的代码适合您的代码，请遵循其他人在您使用的语言中遵循的规则，不要考虑它（或选择另一种语言）。

至于为什么不加前缀，有三个很好的理由：

使用class 关键字时会隐式创建接口，使用type 关键字时也会创建接口。因此，通过向显式声明的接口添加前缀，现在您拥有 some 带有前缀的接口（您自己创建的带有前缀的接口），以及更多不带前缀的接口。这是令人困惑和不一致的。
类型（接口）和代码存在于编译器的独立命名空间中，因此您不能冲突类型名称和变量名称。因此，没有理由尝试通过为接口名称添加前缀来使其唯一。
I 前缀只是系统匈牙利符号的另一种形式；说一个类型是一个接口为编写代码的人提供了零额外的信息。

【讨论】：

@C Snover 它不会告诉编码人员他们正在使用具有多态行为的东西吗？
值得注意的是，截至 2017 年 3 月，微软仍建议在 C# 中使用“I”前缀：docs.microsoft.com/en-us/dotnet/standard/design-guidelines/…
TypeScript 和 C# 不是同一种语言，因此它们没有相同的约定。这很令人困惑，我知道。 ;) Microsoft’s coding guidelines for TypeScript itself 禁止使用 I 前缀。

【解决方案4】：

另外两个原因

模块化 随着代码库的增长，代码开始模块化。模块的通常设计目标是公开合同并隐藏内部。契约最好用接口来表达，一段时间后，即使不是所有暴露的工件都是接口和工厂。对于这些模块的消费者来说，使用Userss 和Credentials 而不是IUsers 和ICredentials 会更好

字母顺序 例如，在文件导航器中按字母顺序排序的列表中快速访问接口和类。与用户一起工作时，最好让User、UserService 和UserImpl 在列表中彼此相邻，而不必依次查看I 条目、C 条目和@ 987654330@条目

【讨论】：

谢谢。实际上我现在已经习惯了，并且现在也意识到 TypeScript 中的接口也比 C# 之类的语言更通用。