Стратегия или командный паттерн?

Question

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

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

Каждое правило должно быть настроено с параметрами (например, ValidateMinimumBalance должен знать, что минимальный баланс = 30). Результат выполнения правила может быть простым: установить код отклонения для объекта транзакции и код ошибки; или это может быть так же сложно, как автоматическое изменение нескольких других свойств транзакции.

Мое базовое понимание шаблонов проектирования указывает мне на шаблоны «Стратегия» или «Команды», но я не совсем уверен, какой из них лучше подходит для этого сценария.

Шаблон команды

1. Каждая команда реализует своего рода интерфейс IValidate
2. Конструктор команды примет экземпляр транзакции в качестве получателя, чтобы иметь возможность прочитать / проверить транзакцию, а также изменить ее аспекты. Конструктор также примет массив пар ключ / значение в качестве параметров для логики проверки.

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

Answer 1

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

---

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

Напечатайте пример реализации сейчас ... но на высоком уровне

Цепочка ответственности Дизайн будет вращаться вокруг чего-то вроде:

abstract class Handler
 {
   protected Handler next;

   public Handler(Handler h){
      this.next = h;
   }
   public abstract bool Validate(Request request); 
   public abstract void Handle(Request request);
}

class CoreLogic: Handler
{   
   public CoreLogic(Handler handle) : base(handle){

   }
   public override void Validate(Request request){
         return True
   }
   public override void Handle(Request request){
        if(this.Validate(request)){
            if(next!= null){
              next.Handle(request);
           }
        }

   }
}

class ValidBalance: Handler
{   
   public ValidBalance(Handler handle) : base(handle){

   }
   public override void Validate(Request request){
        return True
   }
   public override void Handle(Request request){
        if(this.Validate(request)){
            if(next!= null){
              next.Handle(request);
           }
        }

    }
}

class MainApp
{
   static void Main(){
       Handler h = new ValidateBalance( new CoreLogic(null));
       h.Handle(new Request());

   }
}

---

Другие полезные ссылки:

Сеть Википедии ответственности

Answer 2

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

Аналогичная? Он должен выглядеть одинаково.

Различие заключается в том, как работает контекст и делегирование. В принципе, Команда является «активным» агентом. Стратегия вводится в какой-либо активный агент. Это различие довольно тонкое.

Это едва меняет дизайн. Что меняется, так это ожидание.

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

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

Но основной интерфейс во многом такой же.

В большинстве примеров стратегия представляет собой простой объект с одним методом,

Это плохие примеры.

однако в моем случае стратегии потребуется ссылка на транзакцию, а также параметры проверки.

Не необычно. Ничего плохого в этом нет.

Answer 3

но я не совсем уверен, какой из них лучше подходит для этого сценария

Ни то, ни другое :) Я настоятельно рекомендую посмотреть на Интерпретатор .На самом деле ваши правила валидатора - это просто предикаты, сформулированные для ваших транзакций.Вполне возможно, что скоро вам нужно будет объединить эти правила с AND, OR, NOT и т. Д.

Answer 4

Стратегия была бы чем-то, что использовалось бы для «параметризации» Команды (сообщая, как части операции должны быть выполнены).