Java Android架构-为什么要创建单一的实现接口？

我已经做了3年的Android开发人员，我一直想知道为什么要为应用程序架构创建单一实现的界面，比如：

interface SomethingRemote {
   fun fetchSomething(): Single<SomethingEntity>
}

我一直在遵循，从阅读到在我最近的几个项目中实现它，实现新功能或进行更改都是遵循Sunflower的repo体系结构的一件轻而易举的事，但是，我也在一些其他项目中工作过，这些项目做了这个interface interfaceImpl的工作，还向层添加了更多的类：

• 实体
• ViewModel（不要与Google ViewModel混淆，这只是从模型类映射的UI数据）
• 远程执行
• 数据源DatsaSourceImpl
• 存储库RepositoryImpl

所有这些文件和单个实现的接口使得添加新功能或更改简单内容（如修改API请求中的JSON属性值）再次成为一项非常令人困惑的任务，我看到很多项目都在这样做，我不明白为什么在使用Sunflower中所示的体系结构时会这样做，因为它没有那么令人困惑，而且更“切中要害”，我想了解使用这种单一实现的接口方法的好处

---

就我个人而言，.

通常，这要回到测试上来。Mockito风格可以为您提供很多方法，但是通过使用接口，您的测试可以创建更复杂的伪实现，供您的测试使用？使用Sunflower的建议也使代码可测试，非常可测试tbh，而不会使维护工作变得混乱，因此，可测试性是唯一的好处还是更多？而代价是什么？它是如何让人困惑的？我想说的是，很少有争论：1）一些模拟和测试库只能模拟接口，或者模拟类的功能更少2）承诺始终能够以不同的方式实现接口，同时保持两种实现。3） 一个接口可以在不泄漏实现依赖项的情况下公开，即使只有一个实现（考虑gradle模块依赖项api与实现）4）TDD或Clean架构通常开始定义接口，实现在开发的后面process@DaveNewton假设你必须添加一个简单的端点来获取某个列表，你必须为此创建大量文件，对于这个问题，可以使用reformation-POJO/POKO-for-reformation-Interface-DataSource-Interface-DataSourceImpl-repositorymodel-Class-repositoryinterface-repositoryimpl-RemoteMapperToRepositoryModelMapper-UseCase-usecaseinpl-ViewModel/Presenter-UIModel-RepositoryModelToUIModelMapper-Fragment-Activity当这些接口要实现一次时，真的有必要编写所有这些文件吗？

class SomethingRemoteImpl(private val service: apiService): SomethingRemote {
   override fun fetchSomething() {
      // Does some logic with the service class to return the specified class defined in the interface
   }
}