Какой опыт с применением принципа единственной ответственности и принципа открытости-закрытости во фронтенде

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

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

Как отвечать

Начните с формулировок, переложенных на фронтенд:

• SRP: у модуля одна причина для изменения. Компонент, который сам ходит в API, валидирует форму, форматирует даты и рисует разметку, меняется по четырём разным поводам;
• OCP: новое поведение добавляется новым кодом, а не правкой старого. Во фронтенде это композиция, children и слоты, пропсы-рендереры, конфиги и реестры вместо растущего switch.

Дальше нужен пример из своего опыта. Типичный каркас для SRP: запрос вынесен в хук или слой данных (useQuery из TanStack Query, RTK Query), валидация в схему (zod, yup), форматирование в чистые функции, а компонент только отображает. Результат формулируйте проверяемо: схема покрыта тестами без рендера, хук переиспользован на соседнем экране.

Для OCP хорошо работает таблица или форма, где тип колонки выбирается через словарь { date: DateCell, money: MoneyCell }. Новый тип это новая запись в словаре и новый компонент, существующий код не трогается. Другой пример: дизайн-система, где Button принимает icon и as, а не обрастает флагами isIconLeft, isLink, isSubmitLarge.

Если такого опыта нет, так и скажите и разберите реальный код: покажите, как бы вы разделили конкретный толстый компонент и почему именно так. Цифры (на сколько уменьшился файл, что стало покрыто тестами) приводите только свои.

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

Пересказывают определения из SOLID и приводят пример на классах Animal и Dog. Для фронтенд-позиции это звучит как ответ по учебнику, а не по опыту.

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

Трактуют OCP как запрет трогать старый код вообще. Точку расширения стоит заводить, когда второй вариант уже появился, а не на всякий случай: преждевременная абстракция тоже стоит денег.