Архитектура Android - зачем создавать отдельные интерфейсы реализации?

Question

Я работаю разработчиком Android уже 3 года, и мне всегда было интересно, зачем создавать единые реализованные интерфейсы для архитектуры приложения, что-то вроде этого:

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

, а затем реализация:

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
   }
}

Я следил за репозиторием Google's Sunflower , от чтения его до реализации его в моих последних двух проектах и ​​реализации новых функций или внесения изменений - это очень просто послеАрхитектура репозитория Sunflower, но я также работал в некоторых других проектах, которые делают этот интерфейс <-> interfaceImpl, а также добавляют классы в слой:

• Entity
• ViewModel (не путать с Google ViewModel, это просто данные пользовательского интерфейса, сопоставленные с классом модели)
• Remote <-> RemoteImpl
• DataSource <-> DatsaSourceImpl
• Репозиторий <-> RepositoryImpl

Все эти файлы и отдельные реализованные интерфейсы позволяют добавлять новые функции или изменять простые вещи, такие какизменение значения свойства JSON из запроса API - очень сложная задача, опять же, я видел множество проектов, делающих это, и я не понимаю, почему это происходит, когда работа с архитектурой, показанной в Sunflower, менее запутанна и идет более"в точку", я спрашиваю о преимуществах использования этого единого интерфейса.

лично я Я против суффикса "Impl" .