策略还是命令模式? [英] Strategy or Command pattern?
问题描述
假设我有一个金融交易列表，我需要针对这些交易执行验证规则列表.一个例子是我有一个购买产品的交易，但是首先我需要验证交易中的账户有足够的可用资金，产品没有售罄等.由于这些许多规则，交易将是标记为拒绝，并应指定错误代码.
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.
每个规则都需要配置参数(例如，ValidateMinimumBalance 需要知道 minimumBalance = 30).规则执行的结果可以简单到在交易对象上设置拒绝码，以及错误码；或者它可以像自动修改事务的多个其他属性一样复杂.
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.
命令模式
- 每个命令都会实现某种 IValidate 接口
- 命令的构造函数将交易的一个实例作为接收者，以便能够读取/验证交易以及修改交易的各个方面.构造函数还将采用键/值对数组作为验证逻辑的参数.
当我尝试描绘策略模式如何适应这种情况时，它看起来非常相似.在大多数示例中，策略是具有单一方法的简单对象，但在我的情况下，策略将需要对交易的引用以及验证参数.
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.
推荐答案
策略更多地用于交换算法，它并没有真正用于链接验证.如果您打算采用一种模式，其中每种类型都有一个验证，那么您可以使用该策略，如果您发现必须使用多个验证器，或者需要重用验证器.我认为您要么必须找到一种新方法(又名 COR)，要么在您的策略中使用 COR.
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:
这篇关于策略还是命令模式?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
