Использовал ли принципы SOLID во фронтенд разработке

Что проверяют

Для iOS «фронтенд» означает слой интерфейса: экраны на UIKit или SwiftUI и то, что за ними стоит. Интервьюер хочет понять, применяете ли вы SOLID осознанно или пересказываете определения. Следом просят показать принцип на примере из вашего проекта.

Как отвечать

Пройдите по буквам, и к каждой дайте пример из iOS, лучше из своего кода:

• S, единственная ответственность: контроллер не ходит в сеть, не парсит JSON и не форматирует даты. Экран разнесён на view, ViewModel или презентер, сервис и форматтер. Антипример: Massive View Controller на тысячу строк;
• O, открытость для расширения: новый тип ячейки добавляется новой реализацией протокола вроде CellConfigurable, а не новой веткой switch в cellForRowAt;
• L, подстановка Лисков: любая реализация UserRepository, боевая или тестовая, соблюдает один контракт. Мок, который никогда не возвращает ошибку, или ячейка, забывшая вызвать super.prepareForReuse(), его нарушают;
• I, разделение интерфейсов: вместо ServiceProtocol на тридцать методов несколько маленьких протоколов, а экран получает композицию ProfileLoading & AvatarUploading. Так устроен и сам UIKit: UITableViewDataSource и UITableViewDelegate разделены;
• D, инверсия зависимостей: ViewModel зависит от протокола и получает реализацию через инициализатор, в тестах подставляется заглушка. В SwiftUI тот же приём через @Environment.

Опыт подавайте своими примерами и цифрами: какой экран разбили, что стало с тестами и временем на изменения. Если сознательно по SOLID вы не работали, честно скажите и покажите, где принципы уже были без названия, например зависимости через протоколы.

Где спотыкаются

Перечисляют пять определений без единого примера из iOS.

Уходят в переусложнение: протокол на каждый класс с одной реализацией и фабрика ради одного экрана. Сильный ответ говорит и о том, где SOLID не нужен.

Путают инверсию зависимостей с DI-контейнером. Swinject это инструмент, а принцип выполняется и обычным инициализатором.