design-patterns - 保守可能な設計パターンのアドバイス

Question

私は、サービスごとに異なる価格計算を行うプロジェクトに取り組んでいます。例えば：

ホームサービス: キッチン、ベッドルーム、バスルームの数に基づく
ベビーシッター：時間帯・曜日・時間数による（残業含む）
洗車：車の大きさ、座席数による

各サービスは、これらの側面に基づいて異なる方法でコストを計算します。サービスの数が増えるため、各サービスの特定の機能を維持するには、最終的には多すぎる可能性があります。

自分のコードが長期的に保守可能であることを確認するには、どのような設計パターンを使用できますか?

score 0 · Accepted Answer

コンポーネントは型になり、それを, , にServiceサブクラス化できます。したがって、1 つのアクターが 2 つまたは 3 つまたは多くのタスクを実行し、1 回の支払いを受けることができます。各サブクラスには、最終的なコストを計算するサービスメンバーとの独自の支払い計算があり、再帰的に計算されます。タスクごとに新しいサブクラスを追加することで、さまざまなタスクを追加することもできます。HomeServicesBabySittingCarWashingint addCost(int cost)addCost()

score 0 · Accepted Answer

ウォーロックの言うとおり、デコレーターはダイナミックな価格設定に対応する方法です。多くのサービス (ここでのサービスは BLL クラスと見なされます) が必要になりますが、ビジネスニーズに一致するため、それほど多くはありません。

必要なのは、2 つのインターフェース、1 つの汎用サービスインターフェース、および 1 つの価格設定ベースインターフェースです。C# の場合:

interface IBillParameter{
    decimal DefaultCost { get; } // this is assumed if you has default fixed cost, but may be ignored
}

interface IBillCalculator<T> where T : IBillParameter{
    decimal Calculate(T parameter);
}

次のような実装CarServices:

class CarServiceBillParameter :IBillParameter {
    decimal DefaultCost { get{ return 0; } } // for example if does not has any fixed cost
    SizeF CarSize { get;set; }
    int Seat { get;set; }
}

class CarFixedCostBillCalculator : IBillCalculator<CarServiceBillParameter>{
    decimal Calculate(CarServiceBillParameter parameter){
        return parameter.DefaultCost; // this can be replaced by database call, or zero for null pattern
    }
}

class SeatCarServiceBillCalculator : IBillCalculator<CarServiceBillParameter>{
    public SeatCarServiceBillCalculator(IBillCalculator<CarServiceBillParameter> baseCalculator){
        this.baseCalculator = baseCalculator;
    }
    IBillCalculator<CarServiceBillParameter> baseCalculator;
    decimal Calculate(CarServiceBillParameter parameter){
        decimal eachSeatPrice = GetFromDatabase();
        return parameter.Seat * eachSeatPrice + baseCalculator.Calculate(parameter);
    }
}

このように、さらにロジックを追加する必要がある場合は、新しいクラスを導入するだけで済みます。たとえば、タイヤの数によって価格が異なるなどです。

score 0 · Accepted Answer

ストラテジーパターンが頭に浮かびますが、ストラテジーごとに「関数」、より正確にはクラスを作成する必要があります。DI CONtainer を使用すると、ストラテジの数に関係なく問題は発生しません。

アプリに必要なコードの量を減らす魔法のデザインパターンはありません。できることは、コードをより適切に整理することだけです。

design-patterns - 保守可能な設計パターンのアドバイス

3 に答える 3

Related

Reference