策略或命令模式？ [英] Strategy or Command pattern?

问题描述

假设我有金融交易的名单，我有必要执行对这些交易验证规则的列表。一个例子是我有一个交易来购买产品，但首先我需要验证在交易账户有足够的可用资金，该产品是不是卖完了等等。由于这些众多的结果统治交易将标记为拒绝，以及一个错误code应符合规定。

当然我想对我的绕前与规则的接口，允许执行code通过执行每一个直到第一个拒绝交易的规则滚动。

每个规则将要求与参数进行配置（例如ValidateMinimumBalance需要知道minimumBalance = 30）。执行可以像这样的简单规则的结果设置事务对象拒绝code和错误code;或者它可以是一样复杂自动地修改所述交易的多个其他属性。

设计模式分给我我的基本的理解无论是战略或Command模式，但我不完全知道哪一个更适合于这种情况。

命令模式

1. 每个命令将实现某种IValidate接口


2. 该命令的构造将事务作为接收机的一个实例，以便能够读取/验证的事务以及修改它方面。构造函数也将采取键/值对的数组作为验证逻辑参数。

当我尝试想象的策略模式如何适应这种情况下，它看起来非常相似。在大多数例子中的策略是用一个方法的简单对象，但是在我的情况该战略将需要交易的参考，以及验证参数。

解决方案

策略更多的是用来换出算法，它不是真正用于链接验证

。如果你想有一个模式，你必须每输入一个验证，那么你可以使用的策略，如果你发现你不必使用多重校验，或需要重用验证。我想你将不得不找到一条新的方法来做到这一点（又名COR）或战略中使用COR。

---

其实我会回答其他。我认为责任模式和的链=htt​​p://www.dofactory.com /Patterns/PatternComposite.aspx\">composite模式，或验证装饰是为更适合您的需求。

现在打字的示例实现..但在较高的水平。

责任心强的链
该设计将围绕类似：

 抽象类处理器
 {
   保护处理程序下一个;   公共处理器（处理器高）{
      this.next = H;
   }
   公共抽象BOOL验证（请求请求）;
   公共抽象无效手柄（请求请求）;
}类CoreLogic：处理程序
{
   公共CoreLogic（处理程序处理）：基地（手柄）{   }
   公共覆盖无效验证（请求请求）{
         返回True
   }
   公共覆盖无效手柄（请求请求）{
        如果（this.validate（要求））{
            如果（下！= NULL）{
              next.Handle（请求）;
           }
        }   }
}类ValidBalance：处理程序
{
   公共ValidBalance（处理程序处理）：基地（手柄）{   }
   公共覆盖无效验证（请求请求）{
        返回True
   }
   公共覆盖无效手柄（请求请求）{
        如果（this.validate（要求））{
            如果（下！= NULL）{
              next.Handle（请求）;
           }
        }    }
}类MainApp
{
   静态无效的主要（）{
       处理程序H =新ValidateBalance（新CoreLogic（NULL））;
       h.handle（新请求（））;   }
}
 

---

其他有用的链接：

责任心强链维基

Assuming I have a list of financial transactions, I have a need to execute a list of validation rules against those transactions. An example would be I have a transaction to purchase a product, however first I need to validate that the account in the transaction has enough available funds, that the product is not sold out etc. As a result of these many rules the transaction will be marked as rejected, as well as an error code should be specified.

Naturally I am thinking towards fronting my rules with an interface, allowing the executing code to roll through the rules executing each one until the first one rejects the transaction.

Each rule will require to be configured with parameters (ex. ValidateMinimumBalance will need to know that minimumBalance = 30). The result of a rule executing can be as simple as settings the rejection code on the transaction object, and the error code; or it can be as complicated as automatically modifying multiple other properties of the transaction.

My basic understanding of design patterns points to me either Strategy or Command patterns, but I am not entirely sure which one is better suited for this scenario.

Command Pattern

1. Each command will implement some sort of IValidate interface
2. The constructor of the command will take an instance of the transaction as the receiver in order to be able to read/validate the transaction as well as modify aspects of it. The constructor will also take an array of key/value pairs as parameters for the validation logic.

When I try to picture how the Strategy Pattern fits this scenario it looks very similar. In most examples the strategy is a simple object with a single method, however in my case the strategy will need a reference to the transaction as well as validation parameters.

解决方案

Strategy is more used to swap out algorithms, its not really used for chaining validations. If you are going to have a pattern where you have one validation per type then you could use the strategy, if you are finding your having to use multiple validators, or the need to reuse validators. I think you are going to have to either find a new way to do it (aka COR) or within your strategy use the COR.

---

I actually would answer other. I think a combination chain of responsibility pattern and the composite pattern, or decorator for validators is much more suited for your needs.

Typing up an example implementation now.. but at a high level

Chain of Responsiblity The design would revolve around something like:

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());

   }
}

---

Other useful links:

Chain of Responsiblity wikipedia

这篇关于策略或命令模式？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！