Какие еще способы абстракции существуют кроме интерфейсов?

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

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

Как отвечать

Сначала оговорка про стек: в TypeScript interface и type живут только на этапе компиляции и описывают форму объекта структурно, в собранном JavaScript их нет. Поэтому другие способы абстракции во фронтенде даже важнее:

• абстрактные классы: abstract class в TypeScript даёт общую реализацию и обязательные методы наследникам. Встречается в слое данных, например базовый HTTP-клиент;
• функции высшего порядка и замыкания: поведение передаётся параметром, состояние прячется внутри. debounce, фабрики API-клиентов, мемоизация;
• модули: ES-модуль с публичным index.ts скрывает внутренности папки. На этом держатся слои Feature-Sliced Design и правило «импорт только через публичный API»;
• дженерики: useFetch<T>(url) абстрагирует тип данных, а не поведение;
• композиция компонентов: children, слоты через пропсы, render props. Modal не знает, что в нём лежит;
• кастомные хуки: useDebounce, useMediaQuery прячут подписки и эффекты за простым значением. Они вытеснили HOC как основной способ переиспользовать логику;
• размеченные объединения: { status: "loading" } | { status: "done"; data: T } заменяют иерархию классов и проверяются компилятором;
• адаптеры и фасады: слой между компонентами и бэкендом, чтобы смена API не расползалась по коду.

Закончите критерием: абстракция оправдана, когда у неё два-три реальных потребителя и стабильный контракт.

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

Считают, что интерфейс проверяется в рантайме. Ответ сервера TypeScript не валидирует, для этого нужны схемы вроде Zod или Valibot.

Строят иерархию наследования React-компонентов. Документация React прямо советует композицию, наследование компонентов на практике не встречается.

Абстрагируют заранее. Универсальный компонент с двадцатью флагами под один сценарий хуже двух простых, и его труднее выбросить, когда требования изменятся.