Что такое абстрактный класс

Абстрактный класс описывает базу для группы классов. Его нельзя использовать как готовый объект через new, но от него можно наследоваться. Внутри могут быть обычные методы с реализацией и абстрактные методы без тела.

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

Для frontend-разработчика важно добавить TypeScript-нюанс. abstract помогает компилятору поймать ошибку, но не добавляет автоматическую защиту в скомпилированный JavaScript.

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

abstract class BaseLoader<T> {
  async load(url: string, signal?: AbortSignal): Promise<T> {
    const response = await fetch(url, { signal });

    if (!response.ok) {
      throw new Error(`Request failed: ${response.status}`);
    }

    const raw: unknown = await response.json();
    return this.parse(raw);
  }

  protected abstract parse(raw: unknown): T;
}

class UserLoader extends BaseLoader<{ id: string; name: string }> {
  protected parse(raw: unknown) {
    if (!isUserResponse(raw)) {
      throw new Error("Invalid user response");
    }

    return { id: raw.id, name: raw.name };
  }
}

function isUserResponse(raw: unknown): raw is { id: string; name: string } {
  return (
    typeof raw === "object" &&
    raw !== null &&
    "id" in raw &&
    "name" in raw &&
    typeof raw.id === "string" &&
    typeof raw.name === "string"
  );
}

Здесь load уже реализован один раз. Метод parse обязан появиться в каждом наследнике, иначе TypeScript покажет ошибку. Практический плюс в том, что общий порядок сетевого запроса не дублируется, а различающаяся часть остается явно видимой.

Для UI важны две детали. AbortSignal позволяет компоненту отменить запрос при размонтировании или смене параметров. Проверка unknown перед чтением полей защищает от сломанного состояния UI, если API вернул не тот формат.

Абстрактный класс не должен быть первым ответом на любую задачу с типами. Он полезен, когда у вас есть общее поведение, инварианты или шаблонный метод. Если вы просто хотите описать форму объекта, наследование будет лишним.

Интерфейс отвечает на вопрос, какая форма или контракт должны быть у объекта. Абстрактный класс отвечает на вопрос, какая общая база и какие обязательные шаги есть у семейства классов.

Класс может реализовать несколько интерфейсов, но наследоваться только от одного класса. Это важный trade-off. Если вы выбрали abstract class, вы заняли единственный слот наследования и сделали архитектуру более жесткой.

Еще одно различие. Интерфейсы TypeScript полностью исчезают после компиляции. Абстрактный класс тоже теряет сам модификатор abstract, но его обычные методы и поля остаются как JavaScript-код.

Можно ответить так:

Абстрактный класс это класс, который нельзя инстанцировать напрямую. Он служит базой для наследников, может содержать готовую реализацию и абстрактные методы, которые наследники обязаны реализовать. В TypeScript это проверка на этапе компиляции, поэтому я не воспринимаю abstract как runtime-защиту. На практике я использую его, когда есть общий алгоритм или shared-логика. Если нужен только контракт, чаще выбираю interface или type.

Такой ответ показывает не только определение, но и критерий выбора. Это звучит сильнее, чем пример с животными, потому что связывает тему с реальным frontend-кодом и TypeScript.

Если на проекте есть несколько адаптеров, загрузчиков, валидаторов или стратегий с одинаковым порядком работы, abstract class может убрать дублирование и заставить наследников реализовать обязательные шаги. Это снижает риск забыть важный метод.

Но базовый класс не должен скрывать важные для UI решения. Компоненту все равно нужны явные состояния loading, error и empty state, а сетевому коду нужна отмена запроса. Иначе абстракция выглядит чистой, но пользователь видит stale data или ошибку без понятного восстановления.

Если вы описываете данные для компонента, ответ API, событие аналитики или форму config-объекта, не нужно тащить туда абстрактный класс. В таких местах проще типы и композиция. На интервью этот баланс важнее, чем само определение.