Открыт для расширения, закрыт для модификации

OCP: программные сущности должны быть открыты для расширения, но закрыты для модификации. «Закрыт для модификации» значит, что ты можешь выпускать новое поведение, не редактируя существующий, протестированный исходник. «Открыт для расширения» значит, что в дизайне есть шов, куда новое поведение подключается. Вместе они описывают код, который растёт через добавление. Канонический анти-паттерн — условие, переключающееся по тегу типа:

type Shape =
  | { kind: "circle"; r: number }
  | { kind: "square"; side: number };

function area(s: Shape): number {
  switch (s.kind) {
    case "circle": return Math.PI * s.r ** 2;
    case "square": return s.side ** 2;
  }
}

Добавь треугольник — и придётся редактировать area. Добавь периметр — и ты пишешь второй switch по тем же тегам. Этот код закрыт для расширения (без него фигуру не добавить) и открыт для модификации (его приходится постоянно редактировать) — ровно наоборот.

Решение — спрятать вариацию за интерфейс и дать каждому варианту владеть своим кодом. Инвертируй зависимость: вместо одной функции, знающей каждую фигуру, каждая фигура знает, как вычислить свою площадь. switch испаряется в систему типов.

interface Shape {
  area(): number;
}

// circle.ts — целый новый файл
class Circle implements Shape {
  constructor(private r: number) {}
  area(): number { return Math.PI * this.r ** 2; }
}

// square.ts — ещё один файл
class Square implements Shape {
  constructor(private side: number) {}
  area(): number { return this.side ** 2; }
}

function totalArea(shapes: Shape[]): number {
  return shapes.reduce((sum, s) => sum + s.area(), 0);
}

Теперь добавить треугольник — это новый файл, triangle.ts, реализующий Shape. totalArea никогда не открывается. Ничто из того, что уже работало, не тронуто, поэтому ничего из того, что уже работало, не нужно перетестировать. В этом весь выигрыш: радиус поражения «новой фигуры» сжимается с «каждого потребителя» до «одного нового файла».

OCP — это цель вдоль ОДНОЙ оси, а не абсолют: ты выбираешь, какое изменение удешевить. Дизайн с фигурами выше закрыт против добавления фигуры и открыт против добавления операции: новая операция (периметр, ограничивающий прямоугольник) означает редактирование интерфейса Shape и каждого реализующего класса — ровно та боль, что была у switch, просто повёрнутая на 90°. Это проблема выражения: ты можешь сделать дешёвым либо новый-вариант, либо новую-операцию, редко то и другое бесплатно.

Поэтому OCP никогда не «закрыт, и точка». Это «закрыт против той оси, которая, как я предсказываю, будет варьироваться». Если фигуры добавляются часто, а операции редко — полиморфный дизайн выигрывает. Если ты в основном добавляешь операции к фиксированному набору фигур — switch (или visitor) — ставка лучше. Выбор оси и есть проектное решение; паттерн — лишь бухгалтерия после того, как ты выбрал.

Угадай ось неверно — и OCP становится переусложнением: его режим отказа — спекулятивная абстракция. Интерфейс, фабрика, реестр, загрузчик плагинов — каждый из них реальный код для чтения, и каждый — ставка на то, что определённая вариация наступит. Построй фреймворк PaymentProviderPlugin с динамическим обнаружением для продукта, у которого ровно один платёжный провайдер уже два года, — и абстракция не зарабатывает ничего: ты платишь стоимость косвенности при каждом чтении и никогда не получаешь гибкость.

// Спекулятивно: система плагинов под вариацию, которая ещё не появилась.
interface DiscountStrategy { apply(price: number): number; }
class DiscountRegistry { /* register, resolve, fallback, config... */ }
// ...500 строк фреймворка, а приложение отгружает ровно одну скидку: 10%.

Это вотчина YAGNI. Дисциплинированное умолчание — написать конкретный код (price * 0.9) и рефакторить в OCP в момент, когда появится второй реальный вариант — когда ось изменения наблюдаема, а не воображаема. Две точки данных бьют одну догадку.