Для последовательных проверок подходит цепочка валидаторов, для сложного пошагового создания — Builder, для взаимозаменяемых способов оплаты — Strategy. Выбор конкретной стратегии можно отделить фабрикой. Это варианты, а не обязательные шаблоны: простому объекту достаточно конструктора, простой проверке — функции.
Какие паттерны подходят для валидации, создания объекта и выбора способа оплаты?
Цепочка проверок, Builder и Strategy: когда они полезны и почему одна задача не требует единственного обязательного паттерна.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Сначала уточните требования, затем выбирайте форму кода. Совпадение названия задачи с известным паттерном ещё не доказывает, что нужна дополнительная абстракция.
Валидация. Набор независимых проверок можно объединить в цепочку: каждая проверяет своё условие. Заранее решают, завершать ли обработку на первой ошибке или собирать все нарушения. Классическая Chain of Responsibility и pipeline, где проходят все проверки, не полностью одинаковы; важно объяснить выбранное поведение. Для сложных комбинируемых условий может быть полезна Specification.
Создание объекта. Builder помогает собрать сложный объект с несколькими шагами и проверить итоговые инварианты. Если параметров мало, конструктор проще. Factory Method или фабрика отвечают скорее за выбор и создание конкретной реализации, а не обязательно за пошаговую сборку.
Способ оплаты. Strategy отделяет общую операцию от конкретного алгоритма. Условный псевдокод:
PaymentMethod.pay(order, attemptId) -> PaymentResult
CardPayment implements PaymentMethod
BankAppPayment implements PaymentMethod
method = registry.select(order.allowedMethod)
result = method.pay(order, attemptId)
Выбор метода и его исполнение — разные ответственности. Перед выбором проверяют доступность метода для заказа; пользователь не должен назначать произвольный внутренний класс через входные данные.
Strategy сама по себе не обеспечивает безопасность и однократность платежа. Нужны явные состояния результата, обработка неопределённого ответа и идемпотентность по попытке. Не стоит скрывать все ошибки под одним false.
Хороший ответ показывает, какое изменение станет проще: добавить валидатор, вариант сборки или платёжную реализацию. Если этого выигрыша нет, небольшая функция часто лучше лишней иерархии.