Що таке принцип Open-Closed

🟢 Junior Level

Принцип відкритості-закритості (Open-Closed Principle, OCP) — це другий принцип SOLID, сформульований наступним правилом:

«Програмні сутності (класи, модулі, функції) мають бути відкриті для розширення, але закриті для модифікації».

Що це означає простими словами

Закриті для модифікації: стабільний, протестований і працюючий у продакшені код не повинен змінюватися щоразу, коли бізнесу потрібна нова функціональність. Внесення правок у перевірений код створює ризик регресійних помилок у вже працюючому функціоналі.
Відкриті для розширення: система спроєктована так, що нова поведінка додається шляхом написання нового коду (нових класів чи модулів), які підключаються до існуючого каркаса через абстракції.

Життєва аналогія

Смартфон із роз’ємом USB Type-C:

Телефон закритий для модифікації: щоб послухати музику або скопіювати файли, вам не потрібно розбирати корпус і перепаювати материнську плату.
Телефон відкритий для розширення: завдяки стандартизованому інтерфейсу USB ви можете підключити зарядний пристрій, флешку, зовнішню клавіатуру чи ЦАП-навушники.

Приклад порушення OCP (Антипатерн)

У наведеному нижче коді для додавання кожного нового типу сповіщення доводиться модифікувати метод sendNotification:

public class NotificationService {
    public void sendNotification(String type, String message, String recipient) {
        if ("EMAIL".equalsIgnoreCase(type)) {
            // Логіка відправки Email через SMTP
            System.out.println("Sending Email to " + recipient + ": " + message);
        } else if ("SMS".equalsIgnoreCase(type)) {
            // Логіка відправки SMS через SMPP-шлюз
            System.out.println("Sending SMS to " + recipient + ": " + message);
        } else if ("TELEGRAM".equalsIgnoreCase(type)) {
            // Логіка відправки Telegram через Bot API
            System.out.println("Sending Telegram to " + recipient + ": " + message);
        } else {
            throw new IllegalArgumentException("Unsupported channel: " + type);
        }
    }
}

У чому проблема:

При додаванні Push-повідомлень розробник змушений редагувати клас NotificationService.
Існує ризик випадково пошкодити логіку надсилання Email або SMS.
Доводиться заново тестувати весь клас та всі наявні сценарії.
Метод розростається у велетенський блок спагеті-коду (порушення SRP та OCP).

Дотримання OCP через поліморфізм

Виділяємо контракт (інтерфейс) і створюємо незалежні реалізації:

// 1. Стабільна абстракція
public interface NotificationChannel {
    boolean supports(String channelType);
    void send(String recipient, String message);
}

// 2. Реалізація для Email
public class EmailNotificationChannel implements NotificationChannel {
    @Override
    public boolean supports(String channelType) {
        return "EMAIL".equalsIgnoreCase(channelType);
    }

    @Override
    public void send(String recipient, String message) {
        System.out.println("Sending Email to " + recipient + ": " + message);
    }
}

// 3. Клієнтський сервіс — ЗАКРИТИЙ для модифікації
public class NotificationService {
    private final List<NotificationChannel> channels;

    public NotificationService(List<NotificationChannel> channels) {
        this.channels = List.copyOf(channels);
    }

    public void sendNotification(String channelType, String message, String recipient) {
        NotificationChannel targetChannel = channels.stream()
                .filter(ch -> ch.supports(channelType))
                .findFirst()
                .orElseThrow(() -> new IllegalArgumentException("Unsupported channel: " + channelType));

        targetChannel.send(recipient, message);
    }
}

Щоб додати TelegramNotificationChannel, ми створюємо новий клас, який реалізує NotificationChannel. Клас NotificationService не змінюється ні на рядок.

🟡 Middle Level

Архітектурні патерни реалізації OCP

Для дотримання OCP в об’єктно-орієнтованому коді застосовуються класичні патерни GoF:

Strategy (Стратегія): взаємозамінність сімейств алгоритмів через спільний інтерфейс (як у прикладі з каналами сповіщень вище).
Template Method (Шаблонний метод): інваріантний скелет алгоритму визначається в базовому класі, а варіативні кроки перевизначаються в нащадках.
Decorator (Декоратор): розширення функціональності об’єкта на льоту (наприклад, обгортка BufferedInputStream навколо FileInputStream у java.io).
Observer / Event Listener (Слухач подій): нові модулі підписуються на події системи, не модифікуючи видавця подій (ApplicationEventPublisher у Spring).

OCP у Spring Framework: Dependency Injection & Plugins

В екосистемі Spring Framework принцип OCP є фундаментом архітектури. Spring автоматично інжектує всі зареєстровані біни вказаного інтерфейсу в колекцію:

@Service
public class OrderProcessingService {

    // Spring збирає всі біни OrderValidator, зареєстровані в контексті
    private final List<OrderValidator> validators;
    private final Map<String, PaymentProcessor> paymentProcessors;

    public OrderProcessingService(List<OrderValidator> validators,
                                  Map<String, PaymentProcessor> paymentProcessors) {
        this.validators = validators;
        this.paymentProcessors = paymentProcessors;
    }

    public void processOrder(Order order, String paymentMethod) {
        // Виконуємо всі валідації (нові валідатори підключаються без правок сервісу)
        for (OrderValidator validator : validators) {
            validator.validate(order);
        }

        PaymentProcessor processor = paymentProcessors.get(paymentMethod);
        if (processor == null) {
            throw new UnsupportedPaymentMethodException(paymentMethod);
        }
        processor.pay(order);
    }
}

Додавання перевірки на санкційні обмеження (SanctionsOrderValidator) вимагає лише створення нового класу з анотацією @Component.

Expression Problem: OCP vs Sealed Hierarchies (Java 21+)

У сучасній Java (починаючи з Java 17/21) з’явився потужний механізм Sealed Classes / Interfaces та Pattern Matching for switch. Це повертає нас до фундаментальної дилеми computer science — Проблеми Виразів (Expression Problem):

Вимір розширення	Традиційний поліморфізм OCP (Strategy / Interface)	Алгебраїчні типи даних (Sealed Interface + Pattern Matching)
Додавання нового типу (даних)	Легко (OCP дотримано): створюється новий клас-реалізація без зміни наявних класів.	Складно: додавання підтипу в `sealed`-ієрархію вимагає оновлення всіх `switch`-виразів у коді.
Додавання нової операції (поведінки)	Складно (OCP порушується): додавання нового методу в інтерфейс вимагає модифікації всіх наявних класів-реалізацій.	Легко: пишеться нова функція зі `switch`, не зачіпаючи самі типи даних.

Приклад Sealed Pattern Matching:

public sealed interface OrderEvent permits OrderCreated, OrderCancelled, OrderShipped {}

public record OrderCreated(UUID orderId, BigDecimal amount) implements OrderEvent {}
public record OrderCancelled(UUID orderId, String reason) implements OrderEvent {}
public record OrderShipped(UUID orderId, String trackingNumber) implements OrderEvent {}

// Нова операція додається без зміни типів даних:
public class AuditLogService {
    public String describeEvent(OrderEvent event) {
        return switch (event) {
            case OrderCreated created -> "Created order: " + created.orderId();
            case OrderCancelled cancelled -> "Cancelled order: " + cancelled.orderId();
            case OrderShipped shipped -> "Shipped order: " + shipped.orderId();
            // Компілятор перевіряє exhaustiveness: гілка default не потрібна!
        };
    }
}

Висновок для Middle/Senior: використання switch за sealed-типами не є антипатерном OCP. Це усвідомлений вибір архітектури: якщо набір типів фіксований предметною областю, але над ними постійно з’являються нові операції — sealed-ієрархія має перевагу над класичним поліморфізмом.

🔴 Senior Level

Історична еволюція: Bertrand Meyer vs Robert C. Martin

Формулювання Бертрана Меєра (1988, “Object-Oriented Software Construction”):
- Меєр формулював OCP у термінах успадкування implementation-класів.
- Клас закритий, коли він скомпільований і покладений у бібліотеку.
- Клас відкритий, оскільки новий клас може успадкувати його та перевизначити методи.
- Проблема підходу Меєра: Успадкування створює жорстке зачеплення (tight coupling). Зміна внутрішніх деталей предка або побічні ефекти ламають нащадків (Fragile Base Class Problem).
Поліморфний OCP Роберта Мартіна (Uncle Bob, 1996+):
- Переорієнтація з успадкування реалізацій на поліморфізм інтерфейсів та інверсію залежностей (DIP).
- Модулі залежать виключно від стабільних абстракцій. Розширення досягається через додавання нових реалізацій інтерфейсу або композицію (декоратори, стратегії).

Низькорівневий вплив OCP на JVM та HotSpot JIT (C2)

Хоча OCP ідеальний на рівні архітектури, на рівні віртуальної машини поліморфізм має конкретну ціну:

Monomorphic Call Site (1 реалізація):
- JIT фіксує рівно один цільовий клас методу (invokevirtual / invokeinterface).
- Застосовується агресивний Inlining (підстановка тіла методу у викликаючий код).
- Після інлайнінгу спрацьовує Escape Analysis (скалярна заміна об’єктів, розміщення на стеку замість купи, елімінація блокувань).
- Швидкість виклику: ~1 ns (прямий перехід CPU).
Bimorphic Call Site (2 реалізації):
- JIT будує швидку перевірку: if (obj.klass == ImplA) ImplA.method() else ImplB.method().
- Обидві гілки можуть бути заінлайнені компілятором C2.
Megamorphic Call Site (> 2 реалізацій):
- Inline Cache вимикається, JIT деоптимізує виклик.
- Для invokevirtual використовується пошук за таблицею віртуальних методів (vtable).
- Для invokeinterface використовується пошук за інтерфейсною таблицею (itable) або перехід через стаб (Stub calling sequence).
- Наслідки: Інлайнінг неможливий! Escape Analysis не спрацьовує. Прихований оверхед: непрямий перехід за вказівником функції спричиняє скидання конвеєра команд процесора (CPU branch target misprediction) та cache miss по L1/L2 інструкцій (штраф ~15–30 тактів процесора на виклик).

У Highload-системах (Ultra-Low Latency, High-Frequency Trading): Для критичних шляхів (hot path) поліморфізм свідомо усувається через final-класи, прямі виклики чи кодогенерацію на етапі компіляції, щоб гарантувати мономорфний інлайнінг JIT.

Архітектурні межі та blast radius (радіус ураження)

У розподілених та модульних системах OCP масштабується з рівня класів на рівень сервісів та бібліотек:

[UI / REST Controller] ──> (Залежить від) ──> [OrderService Interface]
                                                     ▲
                                                     │ (Реалізує)
                                        [OrderServiceImpl Plugin JAR]

Стабільність API: Інтерфейс ядра оголошується в окремому артефакті (order-api.jar) з мінімальною кількістю транзитивних залежностей.
Java SPI (Service Provider Interface): Механізм java.util.ServiceLoader дозволяє ядру завантажувати реалізації з classpath без жодної залежності часу компіляції на конкретні драйвери (приклад: java.sql.Driver та реалізації від PostgreSQL/MySQL).
Радіус ураження (Blast Radius): Зміна в конкретному плагіні/адаптері зачіпає лише його власний модуль і тести. Час збірки (CI build time) знижується завдяки кешуванню незмінних модулів.

4 Tricky Questions

1. Що первинне в OCP: успадкування за Бертраном Меєром чи поліморфізм за Мартіном, і чому варіант Меєра небезпечний?

Відповідь: Історично первинним є формулювання Бертрана Меєра (1988), яке спиралося на успадкування класів (extends). Проте в промисловій розробці підхід Меєра визнано крихким через проблему базового класу (Fragile Base Class Problem): зміна внутрішньої реалізації предка здатна неявно зламати інваріанти нащадків. Роберт Мартін переосмислив OCP через поліморфізм абстракцій (Polymorphic OCP), поставивши на перше місце слідування принципу підстановки Барбари Лісков (LSP) та перевагу композиції перед успадкуванням.

2. Чи є оператор `switch` по `sealed interface` порушенням OCP?

Відповідь: З точки зору суворого класичного формулювання поліморфного OCP — так, оскільки додавання нового підтипу в sealed-ієрархію вимагає модифікації наявного switch. Проте з точки зору архітектурної концепції Expression Problem — ні. Sealed-типи закривають систему для розширення новими типами даних, але роблять її відкритою для розширення новими операціями без зміни самих класів моделей. Це ортогональний до OCP підхід (функціональна декомпозиція), що гарантує повноту покриття (exhaustiveness check) на етапі компіляції.

3. Як дотримання OCP через виділення 10 стратегій позначиться на продуктивності JVM у Hot-Path циклі?

Відповідь: Виклик методу стратегії стане мегаморфним (Megamorphic call site, коли в точці виклику трапляється понад 2 реалізації інтерфейсу). JIT-компілятор HotSpot (C2) не зможе виконати інлайнінг методів. У результаті:

Виклик відбуватиметься через пошук за itable (interface table) зі штрафом непрямого прогнозування переходів CPU (indirect branch misprediction).
Не спрацює Escape Analysis, і будь-які тимчасові об’єкти, створювані всередині стратегії, виділятимуться в купі (Heap), збільшуючи навантаження на Garbage Collector. В ультра-критичних циклах застосовують мономорфну диспетчеризацію, попереднє сортування даних за типами або явну кодогенерацію.

4. Що робити, якщо нова функціональність вимагає передачі додаткових аргументів в інтерфейс, спроєктований за OCP?

Відповідь: Зміна сигнатури методу в інтерфейсі зламає всіх наявних споживачів (порушення закритості). Для розв’язання застосовують:

Parameter Object (Context Object): сигнатура методу спочатку приймає об’єкт контексту (наприклад, ExecutionEnvironment context чи ValidationRequest request), поля якого можна розширювати без порушення контракту.
Інтерфейс-нащадок або маркерні інтерфейси: введення розширеного інтерфейсу (наприклад, AdvancedNotificationChannel extends NotificationChannel), де викликаючий код перевіряє if (channel instanceof AdvancedNotificationChannel adv).
Default-методи в інтерфейсі (Java 8+): додавання методу з дефолтною реалізацією, що викидає UnsupportedOperationException або делегує виклик базовому методу, зберігаючи зворотну сумісність для решти реалізацій.

🎯 Шпаргалка для інтерв’ю

Головні тези:

Суть: Код має розширюватися додаванням нових класів, а не переписуванням старих.
Головні інструменти: Інтерфейси, поліморфізм, патерни Strategy, Template Method, Decorator, фабрики та Dependency Injection.
Маркер порушення: Розростання ланцюжків if-else / switch із перевірками типів (instanceof), необхідність редагувати старий клас при додаванні нового бізнес-сценарію.
Sealed classes: У Java 21+ вибір між поліморфізмом OCP та sealed switch визначається тим, що частіше розширюється: типи даних (обираємо поліморфізм) чи операції над ними (обираємо sealed + pattern matching).

Чого уникати (Червоні прапорці):

❌ Стверджувати, що заради OCP потрібно створювати інтерфейс для абсолютно кожного класу з єдиною реалізацією (порушення YAGNI та надмірне ускладнення).
❌ Заявляти, що OCP забороняє виправляти баги або рефакторити наявні класи (закритість стосується додавання нового бізнес-функціоналу, а не усунення дефектів).
❌ Ігнорувати накладні витрати поліморфізму (мегаморфізм JIT) у високочастотних highload-сценаріях.