> Что может быть неправильно в решении функции для вычисления площади фигур с использованием типов и интерфейсов TypeScript (TypeScript)

Короткий ответ

Основные проблемы: неправильное использование type narrowing, отсутствие discriminated unions, нарушение принципа открытости/закрытости (OCP) при добавлении новых фигур, избыточное использование any или unknown без проверок, неверная обработка краевых случаев (нулевые/отрицательные значения). Также часто встречается игнорирование readonly для входных данных и отсутствие защиты от NaN.

Подробное объяснение

Типичная ошибка - использование простого enum или строкового literal для идентификации типа фигуры без discriminated union. Это приводит к необходимости писать дополнительные проверки в runtime и усложняет поддержку. Например, если функция принимает { type: string; ... }, то TypeScript не сможет гарантировать корректность полей для каждого типа.

Другая проблема - нарушение OCP: при добавлении новой фигуры приходится модифицировать существующую функцию, а не расширять её. Это делает код хрупким и сложным для тестирования.

Также часто игнорируют валидацию входных данных: не проверяют, что радиус или стороны положительные числа, не обрабатывают случай NaN или Infinity. Использование number без дополнительных guard-ов не защищает от некорректных значений.

Проблемы с типизацией: использование any для параметров, отсутствие readonly для входных массивов/объектов, неправильное применение as для приведения типов вместо proper type narrowing.

На практике

В production-коде лучше использовать discriminated union с явным перечислением всех возможных типов фигур. Для вычисления площади можно применить паттерн visitor или strategy, чтобы избежать больших switch/case. Важно добавить runtime-валидацию с помощью библиотек вроде zod или io-ts, если данные приходят из ненадёжных источников.

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

Пример кода

TYPESCRIPT
// Плохой пример
function calculateArea(shape: any): number {
  if (shape.type === 'circle') {
    return Math.PI * shape.radius * shape.radius;
  }
  if (shape.type === 'rectangle') {
    return shape.width * shape.height;
  }
  throw new Error('Unknown shape');
}

// Хороший пример
type Circle = { readonly kind: 'circle'; readonly radius: number };
type Rectangle = { readonly kind: 'rectangle'; readonly width: number; readonly height: number };
type Shape = Circle | Rectangle;

function calculateArea(shape: Shape): number {
  switch (shape.kind) {
    case 'circle':
      if (shape.radius <= 0) throw new Error('Invalid radius');
      return Math.PI * shape.radius ** 2;
    case 'rectangle':
      if (shape.width <= 0 || shape.height <= 0) throw new Error('Invalid dimensions');
      return shape.width * shape.height;
  }
}

Как отвечать на собеседовании

Начни с конкретного примера плохой реализации, затем объясни проблемы с точки зрения типизации и архитектуры. Покажи улучшенный вариант с discriminated union и валидацией. Упомяни trade-off между строгостью типов и runtime-проверками. Если спросят про расширяемость - предложи паттерн strategy или функциональный подход с map типов.

Что проверяет интервьюер

• Понимание discriminated unions и type narrowing
• Умение проектировать расширяемые типы
• Знание runtime-валидации и её отличий от compile-time проверок
• Способность видеть проблемы в коде с точки зрения SOLID
• Понимание, как TypeScript помогает (или не помогает) в runtime

Типичные ошибки

• Использование interface с общим полем type: string вместо discriminated union
• Применение as для обхода проверок типов
• Отсутствие обработки отрицательных/нулевых значений
• Смешивание вычислений и валидации в одной функции
• Игнорирование readonly для входных параметров
• Использование any или unknown без proper narrowing