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

D в SOLID — это Dependency Inversion Principle, или принцип инверсии зависимостей. Смысл в том, что высокоуровневая логика не должна зависеть от низкоуровневых деталей, а обе части должны зависеть от абстракций. Это помогает делать код более гибким, тестируемым и менее связанным.

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

Принцип инверсии зависимостей говорит о двух вещах: модули верхнего уровня не должны быть привязаны к конкретным реализациям, и конкретные реализации должны зависеть от общих интерфейсов или абстракций. Идея в том, чтобы не создавать жесткую связь между бизнес-логикой и деталями вроде API-клиента, базы данных или файловой системы.

В Flutter это часто означает, что виджет, BLoC, Cubit или сервис получает зависимость через интерфейс, а не создает ее внутри себя напрямую.

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

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

abstract class UserRepository {
  Future<String> fetchUserName();
}

class ApiUserRepository implements UserRepository {
  @override
  Future<String> fetchUserName() async {
    return 'Alice from API';
  }
}

class UserBloc {
  final UserRepository repository;

  UserBloc(this.repository);

  Future<void> loadUser() async {
    final name = await repository.fetchUserName();
    print(name);
  }
}

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

Код показывает, что UserBloc зависит не от конкретного ApiUserRepository, а от интерфейса UserRepository.
Шаг 1: объявляется абстракция UserRepository, которая описывает нужное поведение.
Шаг 2: конкретный класс ApiUserRepository реализует этот контракт.
Шаг 3: UserBloc получает зависимость через конструктор и работает только с абстракцией.
Шаг 4: при необходимости можно подставить другую реализацию, например MockUserRepository в тестах, не меняя UserBloc.

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

Высокоуровневая логика не должна знать о конкретных деталях реализации.
Зависеть нужно от интерфейсов или абстракций, а не от конкретных классов.
DI и внедрение зависимостей — один из основных способов соблюсти этот принцип.
Принцип особенно полезен для тестирования и замены источников данных.
В Flutter это часто применяется в связке с Repository, BLoC/Cubit, сервисами и DI-контейнерами.
DIP уменьшает связанность и упрощает сопровождение кода.

Можете объяснить значение буквы D в принципах SOLID?