Как объяснить провал действия со сложными ограничениями

Question

Я внедряю систему, в которой клиент может использовать ваучеры для получения скидок на покупку. Возможность использования ваучера для определенной покупки зависит от нескольких обстоятельств.

Например:

• Правильный код ваучера - это правильный код?
• Диапазон действия - действует ли ваучер?
• Можно ли использовать ваучер с типом покупки?
• Комбинация разрешена - можно ли комбинировать ваучер с другими ваучерами?
• много еще ...

Есть также несколько более сложных ограничений, которые необходимо проверить. Если одно или несколько ограничений не удовлетворены, клиент не может использовать ваучер, и я хотел бы сообщить ему / ей об ошибке с объяснением «ПОЧЕМУ», он не может использовать этот ваучер, например:

«Вы не можете использовать этот ваучер, потому что он устарел».

Мой вопрос сейчас: Как бы вы осуществили проверки?
Реализовать каждое ограничение в своем собственном классе, объединить их в цепочку и выбросить исключения? (Проблема здесь, возможно, будет выполнено несколько идентичных запросов к базе данных) Реализовать все ограничения в одном методе? (действительно почему?) В целом, как реализовать механизм, в котором вы должны информировать клиента о деталях сбоя, если к действию применяются сложные ограничения?

Спасибо

Answer 1

Лично я бы реализовал проверки только одним способом. Ваучер входит, сообщение об ошибке гаснет (если есть).

Это сохранит весь код, скрытый за этим методом, и упростит обслуживание. Одно место, чтобы проверить, если что-то идет не так, одно место, чтобы изменить при добавлении новых вещей и т. Д.

Если мы говорим о большом количестве тестов, тогда поменяйте метод на класс (но опять же ответственность лежит в одном месте, а сложность не разбросана по всему месту).

Только мои два цента.

Answer 2

Недавно я сталкивался с подобной проблемой проверки заказов, размещенных с помощью одношаговой страницы оформления заказа. В итоге мы обнаружили, что гораздо полезнее создать массив всех соответствующих «проблем» (мы обернули их в простой класс с кодом, отображаемым сообщением и т. Д.), А не строку, описывающую первую возникшую проблему.

Это работает с одним методом проверки, который возвращает массив соответствующих проблем. Основной метод проверки вызывает более конкретные методы проверки для построения массива. Он может пропустить некоторые проверки, если другие уже потерпели неудачу.

Answer 3

Я бы абстрагировал намерение, чтобы на самом деле не имело значения как реализовано или как организован исходный код. На базовом уровне у вас есть набор контролеров, генерирующих набор объяснений ошибок.

Псевдо-код будет в основном:

let reasons be a new, empty collection of failure reasons 
let checkers be the list of relevant checkers

for each checker in checkers
    if checker passes, continue
    if checker fails, add explanation to reasons

if number of reasons is zero, 
    voucher is valid, success
if number of reasons > zero, 
    the voucher is invalid, format each element in reasons for display to the user

С этой логикой не имеет значения, как организованы контролеры, если они могут быть получены этой частью кода в списке. Вы можете иметь один метод с множеством проверок, возможно, добавив множество причин. У вас может быть много классов, по одному экземпляру каждого в списке шашек. Важно отметить, что фактические контролеры отделены от этой логики, и в любое время можно использовать разные контролеры (подумайте об изменении бизнес-правил или разных правил в разных регионах).

В зависимости от вашего языка, это, как минимум, потребует абстрагирования типа, используемого для шашек.

Начните с этого. Если вы обнаружите идентичные запросы к базе данных, начните рассматривать кэш для запуска набора контролеров.

Насколько организованы шашки на уровне источника ... это не имеет значения. Только абстракция делает. Детали достаточно гибкие, когда вы предоставляете уровень абстракции, который вы можете скрыть.

Плюсы:

• Бит, который выполняет проверку, не заботится о реальных, конкретных проверках (которые, вероятно, изменятся в зависимости от бизнес-правил).
• Шашки могут быть организованы так, как вы хотите: определены вместе в одном исходном файле или распределены по какой-то другой схеме. Это также дает свободу выделять одну проверку для тестирования.
• Коллекция и красивое форматирование должны быть реализованы только один раз, независимо от типа или количества проверок.

Минусы:

• Требуется время, чтобы достойно поработать над дизайном абстракций. Это, вероятно, окупится позже.
• Существует слой косвенности, который может усложнить понимание и отследить фактические проверки, которые проводятся. Гибкость в ущерб понятности. Это вещи, которые вы должны будете рассмотреть в своем сценарии. На мой взгляд, правила для ваучеров кажутся чем-то, что может со временем измениться, и абстракции здесь не сложны для понимания, поэтому я бы сказал, что оно того стоит.

Я потратил время на написание примера на Java, но на самом деле он мало что добавил. Если вы попытаетесь мыслить с точки зрения абстракции, реальный механизм менее важен.