Question

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

当然，我正在考虑使用接口来构建我的规则，允许执行代码遍历执行每个规则的规则，直到第一个拒绝事务为止。

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

我对设计模式的基本理解指向了策略或命令模式，但我不完全确定哪一个更适合这种情况。

命令模式

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

当我试图描绘战略模式如何适合这种情况时，它看起来非常相似。在大多数示例中，策略是一个简单的对象，只有一个方法，但在我的情况下，策略需要引用事务以及验证参数。

Answer 1

策略更多地用于交换算法，它并不真正用于链接验证。如果您打算使用每种类型进行一次验证的模式，那么您可以使用该策略，如果您发现必须使用多个验证器，或者需要重用验证器。我认为你将不得不找到一种新方法（也就是COR），或者在你的策略中使用COR。

我实际上会回答其他问题。我认为组合chain of responsibility pattern和composite pattern或decorator for validators更适合您的需求。

现在输入一个示例实现..但是在高级别

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

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

   }
}

其他有用的链接：

Chain of Responsiblity wikipedia

Answer 2

当我尝试描绘策略模式如何适合这种情况时，它看起来非常相似。

类似？它应该看起来完全相同。

区别在于上下文和委托如何工作。原则上，命令是“活动”代理。策略会注入某个活动代理。这种区别非常微妙。

它几乎没有改变设计。改变是什么期望。

命令对象（或多或少）独立存在。他们是为了完成他们的工作而建立的，然后他们就可以消失。没有人再关心他们了。也许他们也使用 Memento 模式，并且有未来的生活，但也许不会。

战略对象（或多或少）与他们注入的对象一起生活。策略将成为更大对象的一部分，并且可以由不同的实现替换，而不会破坏或更改任何其他内容。

但基本界面基本相同。

在大多数示例中，策略是一个简单的对象，只有一个方法，

这些都是不好的例子。

但是在我的情况下，策略需要引用事务以及验证参数。

并不罕见。它没有错。

Answer 3

策略可用于“参数化”命令（告诉它应该如何执行操作的部分）。

Answer 4

但我不完全确定是哪一个更适合这种情况

都不是:) 我强烈建议您查看Interpreter。实际上，您的验证器规则只是为您的交易制定的谓词。你很快就需要将这些规则与AND，OR，NOT等结合起来。

策略或命令模式？

4 个答案: