Как избавиться от кучи if в методе?

Question

[onami]

На собеседование задали такой вопрос: имеется метод, который занимается подтверждением заказов. Потом от бизнеса приходит требование: при подтверждении заказа на сумму более 1000 рублей выдавать этому клиенту скидочный купон на новые покупки. Далее от бизнеса приходит требование для заказов от 10 000 рублей выдавать клиенту постоянную скидку, и так далее.

Вопрос в следующем: как мы можем реализовать эту логику, не превращая метод в кучу if-ов?

Я ответил, что мы можем вытащить эту логику в таблицу, где будут прописаны условия и список операций, который нужно выполнить при выполнении данного условия.

Мне кажется, интервьюер ожидал другого ответа. Может быть, надо было упомянуть какой-нибудь шаблон проектирования (какой, кстати)?

Как бы вы ответили на этот вопрос? Интересно узнать ваше мнение.

Answer 1

[Dmitry Roo]

Похоже на chain of responsibility.
Смысл в том чтобы создавать обработчики заказа, которые будут передавать его друг-другу по цепочке пока в каком-то из них он не будет обработан.

Comments

[BorLaze]

поддерживаю

тоже первое, что в голову пришло

Answer 2

[Александр Скуснов]

Обычно вместо кучи if делают swich case.

Comments

[Александр Интересный]

Тот самый if-else но по другому)

Answer 3

[Василий Банников]

Я думаю, интервьюер чуть более конкретный и развёрнутый ответ, тк таблица сама скидки не назначит и статус клиента не поменяет - этим должен заниматься какой-то вполне определённый код.
И опять же - как должны в эту таблицу условия и действия записываться?

Comments

[Александр Интересный]

Как вариант создать свой мини интерпретатор и выполнять код на своём языке. Если знать хорошо тот самый js - вполне можно такое начудить

[Василий Банников]

Александр Интересный, если вариантов скидок не очень много, то можно и так закодить

[Александр Интересный]

Василий Банников, опять же, а если интервьюер скажет сделать что-бы если заказ от 1000 и только-созданный аккаунт и если это первый у него заказ то одно, не первый заказ - другое, давно созданный аккаунт - третье.

[Василий Банников]

Александр Интересный, для этого не обязательно целый новый язык придумывать.
Можно обойтись мини-DSL в рамках используемого языка.

Вот если бы каждую неделю маркетологи придумывали новую скидку - тогда да, был бы смысл

[Александр Интересный]

Василий Банников, Ну как вариант, но я лично любопытный, в таком случае я бы и полноценный свой lua написал)

[Василий Банников]

Александр Интересный, но это бы вообще задачу не упростило)
Тут скорее что-то типа

(Логическое выражение из предопределённых параметров и флагов) => (размер скидки в процентах или в абсолютном выражении)

Answer 4

[Wataru]

Может хотел от вас услышать, что по таблице можно искать бинарным поиском.

Answer 5

[Therapyx]

именно в данном случае в голвоу полезло следующее, где будет один иф :)
Во первых этот список должен кем-то заполняться и изменяться и уж точно не программистом в хард-коде.
т.е. должна быть там блица по типу key value
1000 - плюшка
10000 - другая плюшка
20000 - ...
n - m

делаем некий адаптер, куда будет передана сумма заказа - загружаем в нём к примеру в сет, который будет отсортирован с этой таблицей.
после чего ищем число которое и через итерацию проверяяем
если число больше, чем текущий индекс и меньше, чем индекс +1 значит это наш range откуда надо достать плюшку из value.

А чего ожидал интервьювер, увы не знаю.

Comments

[Александр Интересный]

А если он захочет сделать следующее:
Если заказ от 1000 рублей и это первый заказ на его аккаунте и у него промокод то одно, если нет промокода то другое, если не первый заказ - третье
Как тогда?)

Answer 6

[vitaly_74]

Я думаю это декоратор или цепочка обязанностей.
Но т.к. у вас речь ведется вокруг одного объекта (заказа) то я думаю это декоратор.

Обработчики в Цепочке обязанностей могут выполнять произвольные действия, независимые друг от друга, а также в любой момент прерывать дальнейшую передачу по цепочке. С другой стороны Декораторы расширяют какое-то определённое действие, не ломая интерфейс базовой операции и не прерывая выполнение остальных декораторов.

Декоратора и цепочка обязанностей очень похожи друг на друга. Подробней о декораторах .

Answer 7

[Алексей Бараношников]

Просто создаются методы вроде "ВыдатьСкидку", "ВыдатьПостояннуюСкиду", "ВыдатьКупон" и вызываются последовательно. Логика каждого метода зашита в методе. В корневом методе никаких if нет. Код читается сверху вниз линейно. Каждый метод в начале имеет проверку условий и если условия не удовлетворяются, то метод сразу выходит. Сложнее будет, если методы будут взаимосвязаны, но это уже другая история.