Kotlin 样式指南 - 同一文件中的接口和实现 - 讨论

如何解决Kotlin 样式指南 - 同一文件中的接口和实现 - 讨论

我现在使用 Kotlin 已经有半年了，之前我只是在项目中使用 Java。基本上我喜欢 Kotlin，因为 Java 的一些痛点被移除了。

但是我仍然在为“糖果店里的孩子”的情况而苦苦挣扎。我想在这个问题中讨论的一个很好的例子是关于将接口及其实现放入同一文件的“功能”：

FooService.kt

interface FooService {
  fun bar()
}

class FooServiceImpl: FooService {
  override fun bar() {
    // ...
  }
}

乍一看，这看起来不错，但恕我直言，这弊大于利。 由于几乎没有关于这些事情的讨论，每次我提到它时，它的论点就像“然后一切都在一个文件中，导航更容易”。这真的应该成为它的论据吗？有时会出现另一个论点“我们总是对一个接口有一个实现，因此它们应该保持在一起”。

缺点是什么？好吧，因为它都在一个文件中，所以 IntelliJ 将它显示为一个文件，即“FooService.kt”，如果我将它拆分，那么我将在项目树中有两个条目，一个名为“FooService”（注意：没有 . kt) 和带有“FooServiceImpl”的第二个条目。所以基本上你需要对 FooServiceImpl 进行类搜索才能找到它（因为文件的名称不同）。

这已经是一个非常具体的观点，所以也许让我们谈谈什么是接口以及为什么要使用它们的想法：它们在那里“隐藏”内部的东西。此外，它应该让您可以从任何外部访问接口，并且实现是“隐藏的”，由您决定提供哪个，用户不应该关心他获得了哪个实现。

最好的例子（即使你总是只有一个实现）是测试。将接口和实现结合在一起，让您可以轻松编写使用 FooServiceImpl 类型的对象的测试，相反，DUT 应该隐藏在接口后面，以防止您访问某些私有/内部内容，这你永远不应该测试。 在这种情况下，假设 FooServiceImpl 需要另一个服务，例如NetworkService，这会导致您想为 FooServiceImpl 测试模拟该 NetworkService，并且在某些情况下，NetworkService 的专用实现比模拟更易于使用/处理。所以现在我们的情况是该接口有多个实现，而不仅仅是一个（即使它只是在测试代码中）。

我不喜欢把它们放在一个文件里的原因有很多，但暂时我停在这里，但仍然感觉这个讨论不可能“赢”，因为它总是感觉没有人被“允许”说你不应该使用一种语言的特定“特性”，因为这是一个很大的“NONO”。

我真的很想听听您对此的意见，我只想问一件事，不允许像“因为我们的代码不需要这个”这样的论点，因为即使它不需要 atm，可能明天。