策略模式还是命令模式？

Question

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

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

每个规则都需要配置参数（例如，ValidateMinimumBalance 需要知道minimumBalance = 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

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

Answer 4

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

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