Что хотят услышать интервьюеры:

Важно показать не только знание названий паттернов, но и понимание, зачем они нужны в реальном коде. Хороший ответ обычно связывает паттерн с конкретной проблемой, которую он решает, и с результатом внедрения. Для junior/middle особенно ценится практический опыт: где применяли, почему выбрали именно этот подход и какой был эффект.

Определение:

Паттерны проектирования — это проверенные решения типовых задач в разработке. Они помогают делать код более гибким, читаемым и поддерживаемым, особенно когда система начинает расти. На практике паттерны используют не ради “красивой архитектуры”, а чтобы убрать дублирование, ослабить связность и упростить изменения.

Пример использования:

Например, в Java я использовал Strategy для расчёта скидок в интернет-магазине. В проекте были разные правила: для новых клиентов, для постоянных, для акций по категориям. Вместо большого if-else вынесли каждую стратегию в отдельный класс, а выбор алгоритма сделали через интерфейс.

interface DiscountStrategy {
    double apply(double price);
}

class RegularCustomerDiscount implements DiscountStrategy {
    public double apply(double price) {
        return price * 0.95;
    }
}

class NewCustomerDiscount implements DiscountStrategy {
    public double apply(double price) {
        return price * 0.90;
    }
}

class OrderService {
    private final DiscountStrategy discountStrategy;

    public OrderService(DiscountStrategy discountStrategy) {
        this.discountStrategy = discountStrategy;
    }

    public double finalPrice(double price) {
        return discountStrategy.apply(price);
    }
}

Пояснение кода:

В этом примере DiscountStrategy задаёт общий контракт для расчёта скидки.
RegularCustomerDiscount и NewCustomerDiscount реализуют разные варианты поведения.
OrderService не знает деталей расчёта и работает только через интерфейс, поэтому при добавлении новой скидки не нужно менять его код — достаточно добавить новую реализацию стратегии и подставить её на этапе создания.

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

Ключевые моменты:

Паттерн стоит упоминать только вместе с решаемой проблемой, а не как абстрактное знание.
Хорошо звучит пример из реального проекта: убрать if-else, снизить связанность, упростить расширение.
Для Java особенно уместны Strategy, Factory Method, Observer, Decorator, Singleton, Adapter.
Важно показать, что паттерн применён осознанно, а не “потому что так принято”.
На собеседовании полезно добавить, какой был эффект: проще тесты, меньше дублирования, легче поддержка.

На каком опыте внедрения или использования паттернов проектирования вы можете поделиться?