策略模式还是命令模式？

假设我有一个金融交易列表，我需要针对这些交易执行一系列验证规则。一个例子是我有一笔购买产品的交易，但是首先我需要验证交易中的帐户是否有足够的可用资金，产品没有售完等。由于这些规则，交易将是标记为拒绝，并应指定错误代码。

当然，我正在考虑用一个接口来呈现我的规则，允许执行代码滚动执行每个规则，直到第一个规则拒绝事务。

每个规则都需要配置参数（例如，ValidateMinimumBalance 需要知道minimumBalance = 30）。规则执行的结果可以很简单，只需在交易对象上设置拒绝代码和错误代码即可；或者它可能像自动修改事务的多个其他属性一样复杂。

我对设计模式的基本理解表明我要么是策略模式，要么是命令模式，但我不完全确定哪一种更适合这种情况。

命令模式

1. 每个命令都会实现某种 IValidate 接口
2. 命令的构造函数将采用事务的实例作为接收者，以便能够读取/验证事务以及修改事务的各个方面。构造函数还将采用键/值对数组作为验证逻辑的参数。

当我尝试想象策略模式如何适应这种场景时，它看起来非常相似。在大多数示例中，策略是具有单一方法的简单对象，但在我的例子中，策略将需要对交易以及验证参数的引用。

策略更多地用于交换算法，而不是真正用于链接验证。如果您打算采用一种模式，其中每种类型只有一个验证，那么您可以使用该策略，如果您发现必须使用多个验证器，或者需要重用验证器。我认为你必须找到一种新的方法来做到这一点（又名 COR），或者在你的策略中使用 COR。

我实际上会回答其他。我认为一个组合责任链模式 http://www.dofactory.com/Patterns/PatternChain.aspx和复合图案 http://www.dofactory.com/Patterns/PatternComposite.aspx, or 验证器的装饰器 http://www.dofactory.com/Patterns/PatternDecorator.aspx更适合您的需求。

现在正在输入一个示例实现..但处于较高的水平

责任链设计将围绕以下内容：

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

   }
}

其他有用的链接：

责任链维基百科 http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern