1

面接でビジネスルールの実装を求められた

要件の変更。彼らはいつもそうします：

  1. 100,000 ドル未満の金額には 20% の手数料がかかります。
  2. $100,000 から $500,000 の間の金額に対して 10% の手数料を課します。
  3. 500,000ドルを超える金額には5%の手数料を課す

任意の金額 x に対する手数料を計算します。

例: $600,000 の請求書の場合、料金は $65,000 になります。

$50,000 の請求書の場合、料金は $10,000 になります。

$200,000 の請求書の場合、料金は $30,000 になります。

私はCofRを使用しましたが、インタビュアーは、n個のように3つ以上の条件がある場合、各要求を処理するためにnクラスを作成するかどうかを尋ねました。

それぞれの条件をチェックする非常に長い再帰関数を書くことはさておき、質問に対するより良いアプローチですか。

4

3 に答える 3

2

インタビュアーは、このような問題に対して一連の責任パターンのようなものが少し過剰に設計されていることをほのめかしていたと思います. また、実装するクラスが実際には同じ責任を負うという議論もあります。それらはすべて、与えられた入力に基づいて、異なるパラメーターを使用して金額を計算するという点です。

私はおそらく2つの単純なクラスでこれを行うでしょう。入力値に基づいてパーセンテージ手数料率を計算し、この率を使用して手数料額を返します。

4 つ目の条件を追加する必要がある場合は、レート計算を含むクラスに追加するだけです。このような単純な問題に対して、これよりも複雑にする必要がある理由がわかりません。

編集：

私は@chrylisと同じように、レートの順序付きリストを処理して計算を実行するクラスがあると考えていました。

class Rate {
    int rangeSize;
    double commission;

    Rate(int rangeSize, double commission){
        this.rangeSize = rangeSize;
        this.commission = commission;
    }

    int computeForAmount(int amount) {
        if (amount <= 0) {
            return 0;
        }
        return (int) (Math.min(amount, this.rangeSize) * this.commission);
    }
}

class FeeCalculator {

    List<Rate> rates = Arrays.asList(
            new Rate(100, 0.2),
            new Rate(400, 0.1),
            new Rate(500, 0.05));

    int calculateCommission(int startingAmount) {
        int commission = 0;
        int remainingAmount = startingAmount;

        for (Rate rate : this.rates) {
            commission += rate.computeForAmount(remainingAmount);
            remainingAmount -= rate.rangeSize;
        }

        return commission;
    }

}

呼び出しによってカプセル化を破ることに完全に満足しているわけではないことは認めますrate.rangeSizeが、それは私が明確にしようとしていた設計を示しています。

于 2013-10-07T23:08:03.373 に答える
0

この場合、単純な戦略パターンで十分だと思います。何かのようなもの：

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

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

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

あなたが提示した単純なビジネス ロジックについては、すべてを 1 つの関数内に実装する方が簡単だと思いますassessFee()。異なる (単純な) ものを実装し、必要に応じて「戦略」オブジェクトを交換できます。料金査定アルゴリズムが、互いに独立した複数のさまざまな要因に依存している場合は、それらをさらに複数の戦略方法に分割できます。

于 2013-10-07T23:20:43.427 に答える