这是一种设计模式吗？

Question

我必须建立一些财务数据报告，并且为了进行计算，有很多“如果那时”的情况：如果它是一个大客户，减去10％，如果它的邮政编码等于'10101'，加10％，如果这个星期六是星期六，难以计算等等。

所以我曾经读过这样的例子，他们所做的是（希望我记得很清楚）创建一个带有一些基本信息的类，并且可以为它添加各种计算对象。

所以把我记得的东西放在伪代码中

Basecalc bc = new baseCalc();
//put the info in the bc so other objects can do their if
bc.Add(new Largecustomercalc());
bc.Add(new PostalcodeCalc());
bc.add(new WeekdayCalc());

bc将运行所有添加的Calc对象的Calc（）方法。 当我键入它时，我认为所有Calc对象必须能够看到Basecalc属性才能正确执行其计算逻辑。

因此所有if都在不同的Calc对象中，而不是在Basecalc中的所有。

这有意义吗？

我想知道这是否是某种设计模式？

Answer 1

正如dtb建议的那样， 责任链似乎最适用于此，略有不同：通常，责任链只找到一个处理程序 ，然后退出。 如果周六有大客户订购，则需要执行两个处理程序。 请注意，这样做是一个非平凡的扩展，因为您的对象可能在平均时间内发生了变化，并且处理程序的顺序变得相关。 这可能非常棘手。 例如，如果有10美元的折扣和10％的折扣怎么办？ 现在，操作顺序有所不同，除非两者都按原价运行。 你猜对了。

重要的是要意识到设计模式并不明确，因此通常没有一个正确的答案。 我仍然相信这与责任链非常接近，并且与已经提到的其他模式相比更进一步。

首先，希望具体实现执行检查它们是否实际适用于手头的项目，这对于责任链来说是典型的。

其次，根据对象中的实际数据，您需要的行为会有所不同。 策略模式简单地封装了基本上实现相同目标的不同算法（即，您可以使用不同的策略来计算10％的折扣，但它们都应该产生相同的值）。

Command模式是执行操作的实际请求的解耦模式，例如，如果您想让其他人计算折扣，您将为此生成一个Command对象。 实际上，（多播）事件的处理程序通常是责任链 。

Composite模式是为树状结构而制作的，您可以像在现实世界中一样组合对象。 这与之前提到的问题有关：如果您将责任链表示为退化子树（没有分支），您将拥有一个有序列表，您可以表示先减去$ 10，然后减去10％或另一种方式之间的差异周围。 从这个意义上说，它可以被理解为一种高度退化的复合材料。 Composite可用于描述特定的折扣方案。 仍然，选择和应用该计划将是责任链的工作。

就像我说的那样，这些并不是明确的术语，它们彼此密切相关，经常出现在变体（和滥用）中，最重要的是，每个模式都需要对您的特定问题进行一些更改。 尽管如此，我仍然倾向于使用一些变体来坚持责任链的术语，因为我认为它最接近你描述的情况。

Answer 2

对我来说似乎是战略模式 。 也许与Composite模式混合，因为您可以将Calculation实现添加到对象中。

Answer 3

在那里似乎有两种模式，取决于你正在看什么。 如果您通过标准的“计算”方法谈论工作委托到项目列表，那么这就是Command模式的一个例子。 如果你在谈论计算器类的实现，那就是Decorator模式 。

Answer 4

它不是责任链，责任链有着完全不同的目的。 它是命令模式（没有撤消/重做）和复合（组合命令）的组合。 正如其他人所指出的那样，你也可以认为它是战略的一部分，但同样也是为了成为战略的一个好榜样而堕落。 有些人可能会称之为“内部DSL”。 正如大多数人所指出的那样：你无法真正定义它是什么，因为它取决于你的观点。 如果你的计算有多个方法，并且遍历算法会调用所有这些 - 或者是一个取决于操作符的子集，例如 - 它将是策略，唯一可以肯定的是“复合”。