Что хотят услышать интервьюеры:

Ожидают понимания, что Dependency Inversion — это зависимость от абстракций, а не от конкретных реализаций. В Android это обычно показывают через работу с репозиторием, сетью, БД или навигацией. Важно уметь объяснить, как это упрощает тестирование и замену реализаций.

Определение:

Dependency Inversion Principle говорит, что высокоуровневые модули не должны зависеть от низкоуровневых напрямую; оба должны зависеть от абстракций. Абстракции не должны зависеть от деталей, а детали должны зависеть от абстракций. На практике это означает, что код бизнес-логики работает с интерфейсами, а конкретные реализации подставляются извне.

Пример использования:

Допустим, экран профиля должен получать данные пользователя. Вместо того чтобы ViewModel создавал сам UserRepositoryImpl, он зависит от интерфейса UserRepository, а конкретная реализация приходит через конструктор.

interface UserRepository {
    suspend fun getUser(id: String): User
}

class UserRepositoryImpl(
    private val api: UserApi
) : UserRepository {
    override suspend fun getUser(id: String): User = api.loadUser(id)
}

class ProfileViewModel(
    private val repository: UserRepository
) : ViewModel() {
    suspend fun loadProfile(userId: String): User {
        return repository.getUser(userId)
    }
}

Пояснение кода:

ProfileViewModel не знает, откуда именно берутся данные: из сети, базы данных или кеша. Ему важно только, что есть контракт UserRepository с методом getUser. UserRepositoryImpl — это конкретная деталь, которая реализует контракт и использует UserApi. При тестировании ProfileViewModel можно подставить FakeUserRepository и проверить бизнес-логику без сети.

Ключевые моменты:

Зависимость строится от интерфейса, а не от конкретного класса.
Бизнес-логика становится проще для тестов и меньше связана с инфраструктурой.
Можно легко заменить источник данных: сеть, БД, кеш или mock.
В Android это часто применяется в ViewModel, use case, repository и навигации.
DIP хорошо сочетается с DI-контейнерами, но сам принцип не равен dependency injection.

Могли бы вы привести пример, когда принцип D в SOLID применяется на практике?