Как добиться, чтобы код был открыт для расширения, но закрыт для изменения?

Принцип Open/Closed (OCP) — второй из пяти принципов SOLID. Его суть: программные сущности должны быть открыты для расширения, но закрыты для модификации. Это значит, что при появлении нового требования мы должны добавлять новый код, а не переписывать существующий. Такой подход снижает риск регрессий и делает систему более предсказуемой.

Почему это важно

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

Как этого добиться

• Выделять абстракции (интерфейсы, абстрактные классы) там, где ожидается вариативность.
• Использовать полиморфизм вместо условных конструкций вида if (type === 'a').
• Применять паттерны: Стратегия, Фабрика, Декоратор, Шаблонный метод.
• Инвертировать зависимости: зависеть от интерфейсов, а не от конкретных реализаций.

Пример на JavaScript

Плохой вариант: метод area знает про все фигуры и требует правки при добавлении новой.

class AreaCalculator {
  area(shape) {
    if (shape.type === 'circle') return Math.PI * shape.r ** 2;
    if (shape.type === 'square') return shape.side ** 2;
    // добавили треугольник — снова правим этот метод
  }
}

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

class Circle {
  constructor(r) { this.r = r; }
  area() { return Math.PI * this.r ** 2; }
}
class Square {
  constructor(side) { this.side = side; }
  area() { return this.side ** 2; }
}
class AreaCalculator {
  total(shapes) {
    return shapes.reduce((sum, s) => sum + s.area(), 0);
  }
}
// Новая фигура — просто новый класс, старый код не трогаем

Где применяется

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

Итог: применяйте OCP там, где ожидается рост числа вариантов поведения — это позволит добавлять функциональность без правки проверенного кода и снизит риск регрессий.