Java Interview Questions

Головна / Усі відповіді / ООП та SOLID

Питання 19 · Розділ 18

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

Уявіть конструктор LEGO: щоб додати дах до будиночка, ви не ламаєте стіни — просто ставите новий блок зверху. SOLID перетворює ваш код на такий конструктор.

Ukrainian ООП та SOLID Вихідний Markdown
Мовні версії: English Russian Ukrainian

🟢 Junior Level

SOLID-принципи — це набір правил проектування коду, які роблять систему легко розширюваною. Головна ідея: коли потрібно додати нову можливість, ви пишете новий код, а не переписуєте старий.

Уявіть конструктор LEGO: щоб додати дах до будиночка, ви не ламаєте стіни — просто ставите новий блок зверху. SOLID перетворює ваш код на такий конструктор.

Приклад без OCP (погано):

public class PaymentProcessor {
    public void process(String type, BigDecimal amount) {
        if (type.equals("card")) {
            processCard(amount);
        } else if (type.equals("paypal")) {
            processPaypal(amount);
        }
        // Щоб додати СБП, потрібно міняти цей метод
    }
}

Приклад з OCP (добре):

public interface PaymentProvider {
    void pay(BigDecimal amount);
}

public class CardPaymentProvider implements PaymentProvider {
    @Override
    public void pay(BigDecimal amount) {
        System.out.println("Card payment: " + amount);
    }
}

public class PaymentProcessor {
    private final List<PaymentProvider> providers;

    public PaymentProcessor(List<PaymentProvider> providers) {
        this.providers = providers;
    }

    public void process(Class<? extends PaymentProvider> type, BigDecimal amount) {
        providers.stream()
            .filter(p -> p.getClass().equals(type))
            .findFirst()
            .orElseThrow(() -> new IllegalArgumentException("Unknown provider"))
            .pay(amount);
    }
}

// Додавання нового способу оплати — новий клас, без змін старого коду
public class SbpPaymentProvider implements PaymentProvider {
    @Override
    public void pay(BigDecimal amount) {
        System.out.println("SBP payment: " + amount);
    }
}

Коли використовувати:

  • Коли ви очікуєте, що функціонал буде рости (нові типи оплати, формати звітів, канали сповіщень)
  • Коли над проектом працює команда з кількох осіб
  • Коли часті релізи і зміни — норма

🟡 Middle Level

Вартість зміни і SOLID

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

Як кожен принцип допомагає розширенню

Принцип Механізм розширення Приклад з проекту
SRP Локалізація правок — зміна однієї відповідальності не зачіпає інші Змінили генерацію PDF-чеків — не зламали розрахунок податків
OCP Додавання нового коду без модифікації старого Новий провайдер оплати — один новий клас, нуль правок в існуючих
LSP Гарантія заміни — нові підтипи працюють в існуючих алгоритмах Новий тип знижки коректно обробляється кошиком без змін
ISP Вузькі інтерфейси — нові клієнти залежать тільки від потрібних методів Мікросервіс сповіщень не тягне весь інтерфейс UserService
DIP Залежність від абстракцій — заміна реалізації без переписування клієнтів Перехід з PostgreSQL на ClickHouse тільки в шарі репозиторію

Типові помилки

  1. Помилка: Додавання нового функціоналу через ланцюжок if-else замість поліморфізму. Рішення: Використовуйте патерн Strategy — кожен if стає окремою реалізацією інтерфейсу.

  2. Помилка: Модифікація існуючого класу при кожній зміні вимог. Рішення: Запитайте себе — чи можу я створити новий клас замість зміни старого?

  3. Помилка: Порушення LSP при розширенні — новий підтип ламає існуючий код. Рішення: Переконайтеся, що новий підтип не кидає неочікуваних винятків і не змінює контракту.

Коли НЕ варто застосовувати SOLID для розширення

  • Прототип / MVP: Швидкість важливіша за розширюваність. Простий if-else краще 10 інтерфейсів.
  • Одноразовий скрипт: Міграція даних, утиліта для логування — тут SOLID тільки сповільнює.
  • Стабільний модуль: Якщо модуль не змінювався 2 роки і не планується — не потрібно його “готувати до майбутнього”.

Порівняння підходів

Підхід Швидкість зараз Швидкість через рік Підтримуваність
Без SOLID Швидко Повільно (спагеті) Низька
З SOLID Повільніше Швидко (конструктор) Висока
Over-engineering Дуже повільно Повільно (10 шарів) Низька

🔴 Senior Level

Internal Implementation: Чому OCP працює

Принцип відкритості/закритості (OCP) працює через динамічну диспетчеризацію (virtual dispatch) в JVM. Коли ви викликаєте метод через інтерфейс:

paymentProvider.pay(amount);

JVM на етапі компіляції не знає, який клас буде викликаний. На етапі виконання використовується vtable (віртуальна таблиця методів), яка дозволяє підставити будь-яку реалізацію без перекомпіляції коду, що викликає. Це і є механізм “розширення без модифікації”.

Performance cost: Віртуальний виклик коштує ~1-3нс проти ~0.3нс для статичного (direct call). JIT-компілятор компенсує це через inline caching — якщо в 95% випадків викликається один і той самий тип, виклик девіртуалізується.

Архітектурні Trade-offs

Повний SOLID:

  • ✅ Плюси: Мінімальний blast radius при змінах; висока тестованість; легка заміна компонентів
  • ❌ Мінуси: Роздування кількості файлів (10-50x); cognitive load; overhead на алокації і виклики

Прагматичний SOLID:

  • ✅ Плюси: Баланс між швидкістю розробки і підтримуваністю; SOLID тільки там, де є реальна варіативність
  • ❌ Мінуси: Вимагає досвідчених архітекторів; потрібно вгадати, що буде змінюватися

Без SOLID:

  • ✅ Плюси: Максимальна швидкість на старті; менше boilerplate
  • ❌ Мінуси: Експоненційний ріст вартості змін; регресії при кожній зміні; неможливість паралельної роботи команд

Edge Cases

  1. Over-Abstraction Trap: Погоня за розширюваністю створює 10 шарів абстракції. Додавання одного поля в БД вимагає правок в Entity → DTO → Mapper → Service → Controller → Request → Response. Рішення: Застосовуйте SOLID тільки там, де бізнес реально очікує змін. Використовуйте YAGNI (You Aren’t Gonna Need It — “вам це не знадобиться”: не створюйте код для гіпотетичних майбутніх вимог) як противагу.

  2. LSP Violation в “невидимій” поведінці: Підтип формально дотримується контракту, але змінює побічні ефекти (наприклад, кешує результат, коли базовий клас не кешує). Рішення: Документуйте не тільки сигнатури, але і побічні ефекти, гарантії консистентності, expectations по кешуванню.

  3. DIP в Legacy-коді: Клас напряму викликає new JdbcTemplate(dataSource) — замінити реалізацію неможливо. Рішення: Використовуйте Strangler Fig патерн (патерн “душуча рослина” — поступова заміна legacy-коду новим, де новий код огортає старий і поступово перехоплює все більше викликів) — поступово огортайте прямі виклики в інтерфейси, перенаправляючи трафік на новий шар.

Продуктивність

  • Inline caching: Hotspot JIT після ~15-30 викликів одного типу деоптимізує віртуальний виклик в прямий. Якщо типи змінюються (megamorphic), виклик йде через itable — ~10-20нс.
  • Memory overhead: Кожен інтерфейс + реалізація = 2 class-об’єкти в metaspace (~1-3KB кожен). При 500 інтерфейсах — ~1-1.5MB metaspace.
  • GC impact: Додаткові об’єкти для делегування (особливо патерн Decorator/Adapter) збільшують алокації в young generation. Для highload-систем з >100K RPS це може бути помітно.

Production Experience

War Story: Платіжна система великого e-commerce (2023)

Команда з 12 розробників підтримувала моноліт на Spring Boot 3.x. Спочатку був один PaymentService з if-else на 15 провайдерів. Кожна нова інтеграція (СБП, SberPay, QR) займала 3-5 днів і вимагала регресійного тестування всього модуля.

Рефакторинг:

public interface PaymentGateway {
    PaymentResult process(PaymentRequest request);
    boolean supports(PaymentMethod method);
}

@Component
public class PaymentOrchestrator {
    private final List<PaymentGateway> gateways;

    public PaymentOrchestrator(List<PaymentGateway> gateways) {
        this.gateways = gateways;
    }

    public PaymentResult process(PaymentRequest request) {
        return gateways.stream()
            .filter(g -> g.supports(request.getMethod()))
            .findFirst()
            .orElseThrow(() -> new UnsupportedPaymentException(request.getMethod()))
            .process(request);
    }
}

Spring автоматично ін’єктує всі @Component реалізації PaymentGateway. Новий провайдер — один новий клас, анотований @Component. Час інтеграції нового провайдера скоротився з 3-5 днів до 1-2 годин. Кількість регресійних багів значно знизилася.

Monitoring і діагностика

  • ArchUnit: Автоматична перевірка SOLID в CI/CD: 
    @ArchTest
static final ArchRule no_service_should_depend_on_concrete_repository =
  classes()
      .that().haveSimpleNameEndingWith("Service")
      .should().onlyDependOnClassesThat().haveNameMatching(".*Repository")
      .orShould().onlyDependOnClassesThat().haveNameMatching(".*Mapper");
  • SonarQube: Метрика “Cognitive Complexity” — якщо метод розширення росте за 15, це сигнал порушення OCP.
  • Regression Rate: Відстежуйте кількість багів в старому коді після додавання нових фіч. Якщо росте — архітектура не SOLID.
  • Lead Time for Changes (DORA metric): В SOLID-проектах залишається стабільним, в “спагеті” — росте з кожним кварталом.

Best Practices для Highload

  • Feature Toggles: OCP + DIP дозволяють тримати дві реалізації (стару і нову) і переключати через конфиг без пересборки. Це критично для canary-деплоїв.
  • Stateless Design (витікає з SRP): Кожен обробник не зберігає стан — легко масштабується горизонтально.
  • Уникайте Speculative Generality (антипатерн “абстракції про запас” — створення інтерфейсів і шарів для гіпотетичних майбутніх вимог): Не створюйте абстракції “на майбутнє”. Досвід показує, що більшість “запланованих” точок розширення ніколи не використовуються.
  • Java 21 Record Patterns + Pattern Matching: Спрощують обробку варіантів без наслідування, але OCP все ще застосовний через sealed interfaces: 
    public sealed interface PaymentMethod permits Card, Crypto, Sbp {}
public final class Card implements PaymentMethod { /* ... */ }
// Компілятор гарантує exhaustiveness — новий тип вимагатиме правок в match,
// але DIP дозволяє додати обробку без зміни існуючого коду.
  • GraalVM Native Image: Статична компіляція ускладнює динамічне розширення (SPI). Потрібна явна реєстрація через @RegisterForReflection і native-image.properties.

Резюме

  • SOLID перетворює монолітну скелю на конструктор LEGO: новий код прибудовується, а не вбудовується.
  • Найкращий код для розширення — це той, який ви не чіпаєте, коли розширюєте систему.
  • SOLID — інвестиція в майбутнє, але інвестиція повинна бути обґрунтованою реальними бізнес-потребами.

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

Обов’язково знати:

  • SOLID перетворює код на конструктор LEGO: новий код прибудовується, а не вбудовується
  • SRP локалізує правки, OCP додає без модифікації, LSP гарантує заміну
  • ISP — вузькі інтерфейси, нові клієнти залежать тільки від потрібних методів
  • DIP — заміна реалізації без переписування клієнтів (PostgreSQL → ClickHouse тільки в репозиторії)
  • Віртуальний виклик ~1-3ns vs direct ~0.3ns; JIT компенсує через inline caching
  • Orchestrator Pattern: Spring ін’єктує всі реалізації, новий провайдер — один клас

Часті уточнюючі запитання:

  • Вартість розширення без SOLID? — Експоненційний ріст: кожна фіча ламає старе, 3-5 днів → 1-2 години
  • Що таке Over-Abstraction Trap? — 10 шарів абстракції, додавання поля вимагає правок в 6+ класах
  • Feature Toggles і OCP? — OCP + DIP дозволяють тримати дві реалізації і переключати через конфиг (canary-деплой)
  • Speculative Generality що це? — Антипатерн “абстракції про запас”; не створюйте те, що ніколи не знадобиться

Червоні прапори (НЕ говорити):

  • “SOLID завжди потрібен для розширення” (прототипи/MVP — швидкість важливіша)
  • “Чим більше абстракцій — тим краще” (10 шарів = over-engineering, cognitive load)
  • “OCP означає, що старий код ніколи не змінюється” (іноді рефакторинг старого — правильний шлях)

Пов’язані теми:

  • [[3. Що таке принцип Open_Closed]]
  • [[9. Навіщо взагалі потрібні принципи SOLID]]
  • [[20. Чи можна слідувати всім принципам SOLID одночасно]]
  • [[22. Які антипатерни суперечать принципам SOLID]]