代表链是否合适？

Question

在一次面试中，我被要求执行一项商业规则。

需求变化。他们总是这样做：

1. 评估20%的费用，任何金额低于100,000美元。
2. 为10万至50万美元之间的任何金额分摊10%的费用。
3. 对500,000美元以上的任何金额征收5%的费用

计算任意金额x的费用。

例句:如果开一张600,000美元的发票，费用应该是65,000美元。

如果发票是50,000美元，费用应该是10,000美元。

如果有20万美元的发票，费用应该是30,000美元。

我使用了CofR，但是面试官接着问，如果他们的条件超过3个，比如n个，我会创建n个类来处理每个请求。

对于这个问题，他们更好的方法是为每个条件编写一个非常长的递归函数检查。

Answer 1

当链的成员有大量不同的规则时，CoR是有帮助的，但在这种情况下，所有规则基本上是相同的(如果数量超过X，则收取一定百分比的费用)。与独立的类不同，只需有一个结构类，它包含最小数量和百分比，另一个类负责查找适当的费用：

class FeeSchedule {
    static class Entry implements Comparable<Entry> {
        int threshold;
        int percentage;

        int compareTo(Entry other) {
            // sort by percentage, descending
        }

    SortedSet<Entry> feeTable;

    int calculateFee(int invoiceAmount) {
        for(Entry e : feeTable)
            if(invoiceAmount > e.threshold)
                return (invoiceAmount * e.percentage);

        // error condition; return 0?
    }
}

Answer 2

我认为在这种情况下，一个简单的策略模式就足够了。类似于：

interface FeeAssessor {
    public double assessFee(double invoice);
}

FeeAssessor feeAssessor = new FeeAssessor() {
        // logic goes here
    };

double calculateFee(double invoice) {
    return feeAssessor.assessFee(invoice);
}

对于您介绍的一个简单的业务逻辑，我认为在一个assessFee()函数中实现它会更简单。您可以实现不同的(简单)对象，并根据需要交换“策略”对象。如果费用评估算法依赖于相互独立的的多个变化因素，那么您可以进一步将它们划分为多个策略方法。