Распространяется ли концепция SOLID на TypeScript
Что проверяют
Отличаете ли вы принципы проектирования от синтаксиса классов. Ответ «SOLID это про ООП, а у нас React» звучит часто и выдаёт, что принципы понимались буквально, по ключевым словам языка.
Как отвечать
Да, распространяется: SOLID про зависимости и границы, а не про слово class. В TypeScript принципы читаются на модулях, функциях, хуках и компонентах.
- Единственная ответственность: компонент либо получает данные, либо рисует. Хук, в котором и запрос, и форматирование, и аналитика, правится по трём разным причинам.
- Открытость и закрытость: расширение через пропсы, слоты и композицию вместо очередного флага
isSomething, дописываемого в условие рендера. - Подстановка Лисков: типизация структурная, поэтому важна не иерархия, а совместимость поведения. Реализация, которая бросает исключение там, где контракт обещает пустой список, ломает вызывающий код.
- Разделение интерфейсов: узкие типы пропсов вместо одного большого объекта, компонент получает то, что использует, а не всю сущность целиком.
- Инверсия зависимостей: модуль зависит от типа, реализация приходит параметром, через провайдер или контекст. Так экран тестируется без настоящего клиента сети.
Добавьте, что принципы это компромисс: дробление ради буквы даёт россыпь файлов, по которой навигация дороже чтения.
Где спотыкаются
Сводят SOLID к классам и наследованию. В типичном фронтенде иерархий почти нет, зато есть модули и хуки, и границы проводятся по ним.
Считают, что тип в TypeScript обязывает так же, как в языке с номинальной типизацией. Совместимость проверяется по структуре, и чужой объект случайно подходит под тип, не разделяя его смысла. От этого помогают брендированные типы.
Применяют принципы ко всему подряд. Абстракция ради единственной реализации и обёртка над клиентом сети, которая ничего не добавляет, обходятся дороже честного повторения кода.