Як принципи SOLID допомагають при розширенні функціоналу

Головна практична цінність принципів SOLID проявляється не в момент написання першої версії застосунку, а в момент додавання нових фічей.

🟢 Junior Level

Головна практична цінність принципів SOLID проявляється не в момент написання першої версії застосунку, а в момент додавання нових фічей.

Без дотримання SOLID додавання нової можливості перетворюється на болісний процес:

Доводиться переписувати класи, що вже працюють.
Випадково ламаються старі, давно протестовані сценарії.
Кілька розробників конфліктують у Git через правки одних і тих самих файлів.

З принципами SOLID код стає адитивним: нова функціональність додається шляхом написання нового коду, а не модифікації старого.

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

Конструктор LEGO проти глиняного виробу:

Щоб додати в будиночок LEGO другий поверх, вам не потрібно ламати фундамент і кришити стіни першого поверху. Ви просто берете нові цеглинки і встановлюєте їх у стандартні пази (інтерфейси).
SOLID перетворює вашу кодову базу на такий набір блоків LEGO.

Наочний приклад: Додавання нового способу оплати

Погано (Без SOLID — модифікуємо монолітний метод):

public class PaymentService {
    public void pay(String method, BigDecimal amount) {
        if ("CARD".equals(method)) {
            // логіка картки
        } else if ("APPLE_PAY".equals(method)) {
            // логіка Apple Pay
        }
        // Щоб додати Crypto, ми змушені редагувати цей клас,
        // ризикуючи випадково зламати оплату карткою!
    }
}

Добре (З SOLID — адитивне розширення):

public interface PaymentStrategy {
    boolean supports(PaymentMethod method);
    void pay(BigDecimal amount);
}

// Додавання криптоплатежів — це створення НОВОГО файлу без зміни наявних!
@Component
public class CryptoPaymentStrategy implements PaymentStrategy {
    @Override
    public boolean supports(PaymentMethod method) { return method == PaymentMethod.CRYPTO; }

    @Override
    public void pay(BigDecimal amount) {
        System.out.println("Processing crypto transaction: " + amount);
    }
}

🟡 Middle Level

Синергія 5 принципів при додаванні нової фічі

Усі п’ять принципів SOLID працюють як єдиний злагоджений оркестр при розширенні функціональності:

[Нова бізнес-вимога]
         │
         ▼
 1. SRP: Локалізує зміну в одному доменному контексті (Blast Radius = 1 модуль).
 2. OCP: Дозволяє підключити новий клас через інтерфейс без правок старих класів.
 3. LSP: Гарантує, що новий клас задовольняє контракт предка і нічого не ламає.
 4. ISP: Захищає новий клас від реалізації непотрібних йому «жирних» методів.
 5. DIP: Забезпечує збірку графа залежностей через контейнер (Spring DI / Plugins).

Принцип	Як конкретно допомагає розширенню	Результат для команди
SRP	Кожна відповідальність ізольована.	Зміна генерації PDF-чека гарантовано не зламає розрахунок податків.
OCP	Точки розширення спроєктовані через поліморфізм.	Додавання фічі = створення одного нового Java-файлу (Zero merge conflicts).
LSP	Новий підтип повністю взаємозамінний зі старими.	Наявний код обробки замовлень працює з новим типом знижки без правок.
ISP	Інтерфейси розділені за ролями клієнтів.	Новому обробнику не доводиться реалізовувати методи-пустушки з винятками.
DIP	Код залежить від інтерфейсів, а не від деталей реалізації.	Підключення нового брокера повідомлень або БД змінює лише шар адаптерів.

Економіка розширення: DORA метрики та Time-to-Market

В IT-індустрії ефективність розширення функціоналу вимірюється метриками DORA (DevOps Research and Assessment):

Lead Time for Changes: Час від коміту першого рядка фічі до її викатки в production. У SOLID-проєктах цей час стабільний і становить години. У «спагеті»-проєктах він зростає до тижнів через тривале ручне регресійне тестування.
Change Failure Rate (Відсоток невдалих релізів): У SOLID-системах дорівнює $< 5\%$, оскільки радіус ураження нового коду суворо ізольований.

🔴 Senior Level

Архітектурні механізми масштабування без модифікації

На Senior-рівні принципи SOLID масштабуються до рівня плагінної архітектури (Plugin Architecture) та незалежних релізних одиниць:

1. Механізм Java SPI (Service Provider Interface)

Дозволяє ядру застосунку розширюватися новими реалізаціями, упакованими в окремі JAR-файли, взагалі без перекомпільовування ядра:

// У модулі ядра core-api.jar:
ServiceLoader<ReportExporter> exporters = ServiceLoader.load(ReportExporter.class);
for (ReportExporter exporter : exporters) {
    if (exporter.supports(format)) {
        exporter.export(data);
    }
}

Нові формати (Excel, Parquet) постачаються окремими залежностями і виявляються в classpath автоматично.

2. Feature Toggles та Canary Deployments на базі OCP/DIP

Дотримання SOLID дозволяє одночасно тримати в кодовій базі дві версії одного компонента (Legacy та NextGen) і перемикати трафік у рантаймі:

@Service
public class RoutingRecommendationEngine {
    private final LegacyRecommendationEngine legacyEngine;
    private final AiRecommendationEngine aiEngine;
    private final FeatureToggleService toggleService;

    public RoutingRecommendationEngine(LegacyRecommendationEngine legacy,
                                       AiRecommendationEngine ai,
                                       FeatureToggleService toggleService) {
        this.legacyEngine = legacy;
        this.aiEngine = ai;
        this.toggleService = toggleService;
    }

    public List<Product> getRecommendations(UserId userId) {
        // Плавна канареєчна викатка: 10% користувачів на новий AI-рушій
        if (toggleService.isAiEngineEnabled(userId)) {
            return aiEngine.getRecommendations(userId);
        }
        return legacyEngine.getRecommendations(userId);
    }
}

Завдяки спільному інтерфейсу відкат при виявленні інциденту займає 1 секунду зміною прапорця в Redis/Consul без передеплою застосунку.

Аналіз компромісів: Speculative Generality проти YAGNI

Найчастіша пастка при спробі спроєктувати «масштабовану систему» — антипатерн Speculative Generality (Спекулятивна генералізація):

Розробник намагається передбачити всі можливі майбутні розширення на 3 роки вперед і створює 15 шарів абстракцій, фабрик та адаптерів.
У 90% випадків бізнес змінюється в зовсім іншому, непередбачуваному напрямку, і ці «точки розширення» стають мертвим тягарем, що сповільнює команду.

Senior-принцип: Проєктуйте точки розширення (OCP/DIP) тільки тоді, коли вже є дві різні реалізації (правило трьох «Rule of Three»), або коли ймовірність появи нових варіантів документально підтверджена продуктовим роадмапом.

4 Tricky Questions

1. Як SOLID допомагає уникнути merge-конфліктів при паралельній роботі 5 команд над однією системою?

Відповідь: Завдяки OCP та SRP. Коли архітектура не розділена за SOLID, усі 5 команд вносять зміни в один монолітний файл OrderService.java (дописуючи свої гілки if, поля та методи). При спробі злити гілки в Git виникають складні merge-конфлікти, небезпечні затиранням чужого коду. При дотриманні SOLID команди створюють нові незалежні файли у своїх пакетах (ApplePayPaymentStrategy.java, CryptoPaymentStrategy.java), що реалізують спільний інтерфейс. Оскільки наявний код ядра не редагується, конфліктів злиття в Git не виникає фізично.

2. Чи може додавання нової фічі за правилами SOLID погіршити продуктивність системи під високим навантаженням?

Відповідь: Так. Додавання поліморфних абстракцій замість простого if-else у циклі Hot-Path:

Замінює мономорфний виклик машинного коду на мегаморфний пошук за таблицею itable у JVM (штраф ~10–20 нс на виклик).
Блокує JIT-інлайнінг та усунення алокацій через Escape Analysis.
Породжує додаткові обгортки та дрібні об’єкти (наприклад, патерн Decorator), збільшуючи навантаження на збирач сміття GC. У Low-Latency ділянках (обробка біржових заявок) розширюваність свідомо приноситься в жертву прямій процедурній швидкості.

3. Як дотримання LSP захищає від регресійних багів при розширенні функціоналу?

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

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

Відповідь: Пряме додавання методу в базовий інтерфейс порушить OCP та ISP, змусивши всі наявні реалізації переписуватися або писати порожні заглушки. Рішення:

Interface Segregation (ISP): Створити спеціалізований інтерфейс-розширення: public interface RefundablePaymentProvider extends PaymentProvider { void refund(); }. Клієнтський код, якому потрібне повернення коштів, перевіряє if (provider instanceof RefundablePaymentProvider r) r.refund();.
Default методи (Java 8+): Додати метод із дефолтною безпечною реалізацією (наприклад, що повертає Optional.empty() або викидає зрозуміле UnsupportedOperationException).
Патерн Extension Object / Adapter: Винесення специфічного розширення в адаптер.

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

Головні тези (30 секунд на відповідь):

Головний принцип розширення: OCP (Open-Closed Principle) — додавання нового коду замість переписування старого.
Роль усієї п’ятірки:
- SRP ізолює радіус ураження.
- OCP надає точки входу (Strategy, Plugins).
- LSP гарантує, що новий клас не зламає старі сценарії.
- ISP рятує новий клас від непотрібного тягаря методів.
- DIP збирає граф компонентів через впровадження залежностей.
Вплив на процеси: Різке скорочення merge-конфліктів у Git, прискорення Lead Time for Changes, можливість безпечного Canary-розгортання через Feature Toggles.

Чого уникати (Red Flags):

❌ Створювати точки розширення на кожен клас «про запас» (порушення YAGNI / Speculative Generality).
❌ Правити старий працюючий метод із додаванням 5-го else if замість виділення стратегії.
❌ Додавати специфічні методи в загальні інтерфейси, порушуючи ISP для решти реалізацій.