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

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

Вопрос сформулирован про фронтенд, но для Android-разработчика речь об UI-слое: экранах, ViewModel, адаптерах. Интервьюер хочет услышать не пять определений, а случаи из вашего кода, где принцип что-то решил. Следом часто просят назвать место, где SOLID вам мешал.

Как отвечать

Стройте ответ на своих примерах, по одному на принцип, там, где он действительно был. Каркас такой:

• SRP: Activity или composable только рисует состояние, ViewModel готовит StateFlow с состоянием экрана, репозиторий ходит в сеть и базу. В Compose это ещё и state hoisting: composable без состояния получает данные и лямбды параметрами, поэтому легко переиспользуется и попадает в превью;
• OCP: новый тип элемента ленты добавляется новым делегатом адаптера, а не очередной веткой when в onBindViewHolder;
• LSP: наследник обязан выполнять контракт родителя. Своя View, которая в onMeasure не вызвала setMeasuredDimension, падает с исключением в любом контейнере. Так же фейковый репозиторий в тестах должен вести себя как настоящий: отдавать Flow так же и бросать те же ошибки;
• ISP: TextWatcher заставляет реализовать три метода ради одного, поэтому в core-ktx появились doAfterTextChanged и родственные расширения. Свои колбэки дробите так же, для одного метода подходит fun interface;
• DIP: ViewModel зависит от интерфейса UserRepository, реализацию подставляет Hilt через @Binds, в тесте передаётся фейк.

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

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

Рассказывают учебные Shape и Vehicle вместо своего кода. Интервьюер спросит, где это было в проекте, и ответа не будет.

Путают DIP с DI. Dagger и Hilt это инструменты внедрения зависимостей, а принцип про направление зависимости: от абстракции, а не от реализации.

Переворачивают LSP и говорят, что родителя можно подставить вместо наследника. Всё наоборот: наследник должен работать везде, где ждут родителя.