Почему не стоит слепо следовать SOLID

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

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

Как отвечать

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

Примеры из своей области:

• протокол с единственной реализацией «на будущее» ломает навигацию по коду: переход к определению приводит в объявление, а не в логику. Он оправдан, когда подмена реально нужна, например мок сетевого слоя в тестах;
• any Protocol это динамическая диспетчеризация и упаковка значения, some Protocol и дженерики разрешаются на этапе компиляции. Если абстракция заводится ради чистоты на горячем пути отрисовки, цену стоит хотя бы знать;
• наследование от UIView и UIViewController регулярно нарушает принцип подстановки, потому что наследник меняет ожидания базового класса. Композиция и дочерние контроллеры дают то же самое без сюрпризов;
• раздутый экранный контроллер лечится выносом в отдельные типы, а не дроблением на десяток микрообъектов, между которыми потом невозможно проследить сценарий.

Закончите критерием: абстракцию заводим, когда есть вторая реализация, тест, который иначе не написать, или граница между командами. «Вдруг понадобится» не критерий.

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

Пересказывают расшифровку букв и не называют ни одной ситуации, где принцип спас или помешал. Это ответ по учебнику, и первый же вопрос про свой проект его обнуляет.

Понимают «не слепо» как «не надо вовсе» и уходят в другую крайность: вся логика в контроллере, тестов нет, потому что принципы переоценены. Ответ должен звучать как выбор, а не как отказ.

Читают принцип единственной ответственности как «один тип, одна функция» и режут код на россыпь крошечных сущностей. В исходной формулировке речь про одну причину для изменения, то есть про то, кто и зачем придёт править этот код.