SOLID на примерах из фронтенда
Вопрос
Расскажи про SOLID и приведи пример каждого принципа из фронтенд-разработки.
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
SRP: одна причина изменения; пример: загрузка в хуке, бизнес-правило в функции, компонент рисует
OCP: расширение без правки; пример: children, слоты, словарь рендереров вместо switch
LSP: замена не ломает контракт; пример: свой Input ведёт себя как нативный
ISP: компонент получает только нужные пропсы, а не весь объект из стора
DIP: зависимость от абстракции; пример: API-клиент или аналитика через Context или параметр, подмена в тестах
Оговорка: принципы применять по ситуации, без лишних абстракций (YAGNI)
Что могут спросить следом
- Где SOLID во фронтенде вредит?
- Чем DIP отличается от DI?
- Как SRP связан с размером компонента?
Разбор
SOLID пришёл из ООП, но во фронтенде отлично ложится на компоненты и хуки. SRP: у модуля одна причина для изменения. Если компонент и грузит данные, и считает скидки, и рисует, он поменяется по трём поводам, поэтому загрузку выношу в хук, правило в чистую функцию. OCP: новое поведение добавляется новым кодом. В React это children и слоты, или словарь «тип → компонент» вместо растущего switch. LSP: если я делаю свой Input как замену нативному, он должен вести себя так же, например onChange с событием. ISP: компонент получает только то, что использует, тогда он реже перерисовывается и проще тестируется. DIP: компонент не импортирует конкретный axios или SDK аналитики, а получает абстракцию через Context или параметр, и в тестах я подставляю заглушку. И важная оговорка: интерфейс с одной реализацией «на будущее» нарушает YAGNI, так что применяю принципы, когда они реально удешевляют изменения.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.