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

Основная проблема в таких решениях - нарушение принципа открытости/закрытости (OCP) и избыточная связанность через проверку типа. Например, если функция вычисления площади принимает Shape и внутри делает switch по shape.kind, то при добавлении новой фигуры (например, треугольника) придётся менять саму функцию, а не расширять систему. Это ведёт к ошибкам и усложнению поддержки.

Правильный подход - использовать полиморфизм через интерфейс: каждая фигура реализует метод area(). Тогда функция просто вызывает shape.area(), не зная деталей. Типичные ошибки: забыть сделать поле kind дискриминирующим (например, не использовать type с литеральным типом), неправильно задать типы для свойств (например, radius как number | string), или не учесть, что интерфейс может быть расширен без нарушения контракта.

Пример плохого кода:

TYPESCRIPT
interface Shape {
  kind: string; // не литерал
  radius?: number;
  width?: number;
  height?: number;
}
function area(shape: Shape) {
  if (shape.kind === 'circle') return Math.PI * shape.radius! ** 2;
  // ... switch
}

Проблемы: kind не сужается, radius может отсутствовать, нет гарантии корректности.

Хороший вариант:

TYPESCRIPT
interface Shape {
  area(): number;
}
class Circle implements Shape {
  constructor(private radius: number) {}
  area() { return Math.PI * this.radius ** 2; }
}
function calculateArea(shape: Shape) {
  return shape.area();
}

Такой код легко расширяется, типизирован и не требует изменения существующей логики.