C# 这是一种设计模式吗？

我必须建立一些财务数据报告，为了进行计算，有很多“如果-那么”的情况：如果是大客户，减去10%，如果邮政编码等于“10101”，再加上10%，如果是星期六，进行困难的计算等等

所以我曾经读过这类例子，他们所做的是（希望我记得很清楚）创建一个包含一些基本信息的类，并使其能够添加各种CalculationObject

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

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中

这有意义吗

---

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

根据您所看到的情况，似乎有两种模式在起作用。如果您正在谈论通过标准的“计算”方法将工作委托给项目列表，那么这就是一个示例。如果你说的是计算器类的实现，那就是。

对我来说似乎是最好的选择。可能与混合，因为您可以将计算实现添加到您的对象中。

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

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

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

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

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

复合模式是为树状结构设计的，在树状结构中，您可以像在现实世界中一样组合对象。这与前面提到的问题有关：如果你将你的责任链表示为退化子树（没有分支），你将有一个有序的列表，你可以表示先减去$10，然后减去10%或其他方式之间的差异。从这个意义上讲，它可以理解为一种高度简并的复合材料。该组合可用于描述特定的贴现方案。不过，选择和应用该计划将是责任链的工作

---

正如我所说的，这些都不是明确的术语，它们之间有着密切的联系，经常出现在变体（和滥用）中，最重要的是，每个模式都需要针对您的特定问题进行一些修改。尽管如此，我还是倾向于使用责任链的术语，但有一些变化，因为我认为它最接近您描述的情况。

这不是责任链，责任链有完全不同的目的。它是命令模式（无撤消/重做）和复合（组合命令）的组合。正如其他人指出的，你也可以认为它是一个战略的一部分，但它又是退化作为一个战略的一个很好的例子。有些人可能会称之为“内部DSL”。

---

正如大多数人指出的：你不能真正定义它是什么，因为它取决于你的观点。如果您的计算有多个方法，并且遍历算法将调用所有方法，或者根据操作对象（例如）调用一个子集，这将是策略，唯一可以确定的是“组合”。

听起来您在寻找装饰器模式？（有点）这听起来确实和“头先设计模式”（他们以计算热饮料价格为例）中对装饰师的描述非常相似，也许你在那里读到了？责任链模式或战略模式可能？责任链看起来很像复合模式，是吗？@Brian Roach:我刚刚读到的关于decorator对象的例子都是关于添加到组件的decorator（正如我所希望的，计算器添加到基本对象中），但是在这些例子中，所有的decorator都是为了他们自己，他们没有与组件交互。装饰者也可以改变组件对象的状态吗？我已经读过这个策略：“更简单地说，一个对象及其行为被分离并放入两个不同的类中。这允许你随时切换你正在使用的算法。”这听起来是我想要做的，我会检查合成图的。我也在想策略+合成。对！订购也必须是一个问题。非常感谢你的详尽回答！