割引モデルに適用される設計パターンはありますか？

割引モデルを実装するための既知の設計パターンはありますか？

割引モデルとは、次のことを意味します。

1. 顧客が製品X、製品Y、および製品Zを購入すると、10％または100ドルの割引を受けます。

2. 顧客が製品Xを100単位購入すると、15％または$ 500の割引を受ける

3. 顧客が昨年に10万ドル以上持ち込んだ場合、20％の割引が適用されます

4. 顧客が製品Xを2ユニット購入した場合、製品X（または製品Y）を1ユニット無料で入手できます。

5. ...

上記のすべてのシナリオを処理するために適用できる一般的なパターンはありますか？私はいくつかのモデルを考えていますが、一般的なモデルに出くわすことはできません。

特定の状況下で複数の割引を適用する必要があるという問題がある場合は、責任の連鎖パターンを検討することをお勧めします。

簡単に言うと、処理する情報を最初のプロセッサに渡し、そこから結果を返す前に他のプロセッサに渡すかどうかを決定します。

これにより、呼び出しコードを変更することなく、プロセッサの構造とシーケンスを変更できます。

戦略、デコレーター、および状態のパターンは、潜在的な出発点として際立っています。2は注文の状態に依存し、3は一定期間内の顧客の状態に依存するため、状態は2または3に特に役立ちます。Strategyを使用して複数の注文価格計算アルゴリズムとデコレータを実装し、注文に新しい割引を追加できるため、Strategy and Decoratorは他の製品よりも優れています。

ただし、設計パターンは単なるモデルであることを忘れないでください。適用される単一のパターンではなく、パターンのシステムがある場合があります。また、記述されたモデルを修正して、ソリューションにより適合させることを検討してください。パターンがあると言うことができるためだけに役立つとは限らないパターンを強制するよりも、良いデザインを持つ方が良いです。

まあ、私は「Precondition」と「Discount」のペアとして割引モデルを設計します。「Precondition」はメソッドを持つクラスです

  bool IsFulfilled(Customer c);

または

  bool IsFulfilled(Customer c, Order o);

と割引には方法がありvoid ApplyTo(Customer c)ます。これにより、あらゆるタイプの前提条件とあらゆるタイプの割引を組み合わせることができます（これは「ブリッジパターン」の一種だと思います）。

前提条件の数が決まっている場合、特定のサブタイプ（戦略パターン）を作成することで問題を解決できます。ただし、AND、OR、NOTなどの論理ステートメントを使用して前提条件を非常に複雑にすることが許可されている場合は、条件に対して何らかの種類のルールインタープリターを実装することをお勧めします。ルールは、単純な「ドメイン固有言語」で記述されたプレーンテキスト文字列にすることができます。

「Discount」クラスについても同じことが言えます。さまざまなタイプの割引にいくつかのサブタイプを設定するか、割引ルールをテキスト形式で指定し、インタープリターが評価する一般的なアプローチを使用できます。

• おそらく、すべての異なる割引は同じものであるため、IDiscountインターフェイスが必要になります。これらを一般的な割引として概念的に扱いたいと思います。

• 「この顧客の注文」クラスには、おそらく割引のコレクションが必要です。リスト？ハッシュ？リンクリスト？まだ気にしません。割引は顧客ではなく購入に適用されます！

• 顧客、ショッピングカート、履歴などとは別の割引インスタンスを作成してください。@ jfrankcarrが指摘したように、大幅に変更されます。

• おそらく、各割引のアルゴリズムとパラメーターは大きく変化し、予測できないため、各割引には異なるクラスがあります。

• 割引計算はショッピングカートの変更に対応し、その逆も同様であるため、多くのイベント処理が見られます。

デザインパターンアプリケーション

• が表示されますstrategy pattern。IDiscountは、さまざまな割引アルゴリズムを実装するためのインターフェイスです。

• が表示されますfactory。確かに本格的なものではなくabstract factory pattern、分析のこの時点での単一のクラスです。合理的には、どの割引が適用されるかを決定し、それを作成するのに十分なコンテキストがある単一の場所がなければなりません。1つのクラス。マーケティング部門のマッシュルームパーティーのために割引を適用するためのルールが後で爆発する場合、追加の割引構築ロジックは、この基本ファクトリクラスでまだ結合する必要があると思います。

• 見えChain of Responsibilityます。これは、factoryアイデアと相互に排他的ではありません。割引コレクションを繰り返す代わりに、各割引は次の人を呼び出します。この場合、「顧客の注文」クラスは割引のコレクションを保持しません。

• Chain of Responsibilityの「うーん...」要素は、各割引には次への参照があるということだと思います。意味は、順序が重要であることです。そうではありません。また、CoRが具体化する概念は、1つのオブジェクトが要求を処理できないため、「次の上位の権限まで」渡されるということです。私たちのモデルは異なります。唯一の要求は計算することです。すべての割引はこれを行います。出力または効果はnullでもかまいませんが、すべての割引が計算されます。私は本能的に、より高い実世界の忠実度に傾いています。

仮定

• 割引は、現在のショッピングカートや購入履歴に基づいています
• ゼロ以上の割引が適用される場合があります。相互に排他的な割引はありません
• 適切な計算は、割引が適用される順序に依存しません。

何が変わり、何が変わらないのか？

• 割引は非常に異なります。各ルールを構成するパラメーターの数と種類が異なります。

• 適格な割引の引数は、ショッピングカートが変わると変わります。

• 利用可能な割引の数の変更

• この顧客の割引は、ショッピングカートの変更に伴う変更の対象となります。

• この購入のコンテキストではショッピング履歴は変更されません

• 総費用は、購入ラインと適用される割引の関数として動的に変化します。

• 最初の適用後、割引の出力は、たとえば購入数量が変わると変化する場合があります。

論理的には、割引モデルは何でもかまいませんので、すべてのケースを事前にプログラムできるとは限りません。あなたの質問に答える誰もがあなたが実際に必要とするものを完全に確信することもできません。ただし、現実の世界で見られる通常の種類の割引を受けると仮定すると...

大きな質問は、割引をプログラムするかどうか、またはユーザーに割引を入力してもらうかどうかです。前述のように、それらをプログラムすることはできませんが、通常は、すべてをプログラミングするのではなく、一般的な場合のようにデータ入力を増やすことを目標とします。プログラマーがすべての割引を作成するために使用されている場合でも、これはある程度適用されます。

マーティン・ファウラーは、会計システムに「転記ルール」を実装する方法の一部として、「分析パターン：再利用可能なオブジェクトモデル」の「個別インスタンスメソッド」に言及していますが、ルールはかなり似ています。詳細をお伝えしますが、著作物です。

ユーザーインターフェイスの場合は、かなり単純なユースケースを考え出すか、インタープリターとクエリビルダーを構築する必要があります。1つは単純なケース用で、もう1つはより高度なものです。インタープリターを作成する場合、パーサージェネレーターと比較してコーディングが比較的簡単であり、解析時間が遅いことはおそらく重要ではないため、これはインタープリターパターンを使用するためのかなり良いケースです。（パーサージェネレーターを使用したい場合は、私を止めさせません）。

ただし、インタープリターですべてをやろうとしないでください-ある時点で、あなたは自分の不器用な言語でプログラミングしているだけなので、実際の言語を使用することもできます。インタプリタ言語が関数をサポートしている場合（おそらくそれらの呼び出しをサポートする必要があります-それらの定義は疑わしいです）、それらは実際の言語でコーディングできます。必要以上にこの道を進んで行かないでください。

何をするにしても、最終的に誰かがプロモーションの30営業日以内に購入したかどうかに基づいて割引を希望します。営業日は、店舗の郵便番号またはクライアントのいずれかによって定義される地域に休日がない郵便番号。したがって、事前に完全なシステムを設計しようとしないでください。新しい種類の割引のためにコードを記述する必要がある場合があると想定し、それに応じて設計してください。

これに役立つパターンがあるかどうかを尋ねるポイントはありますか？どのタイプのパターンが必要ですか-構造的または行動的ですか？

理想的には、このためのソフトウェアを作成する場合、必要なのはアルゴリズムのみです。次のように合計割引を計算する単純な関数：

cart.calculateDiscount(productVector);

これ以上必要なものはありません！

明確にするために、私は多くのルールがあることを理解しています-そのような表現の最も基本的なものはルールベース（データ属性のセットとその結果の割引）であり、上記のような関数はそれを反復して計算する必要があります。ルールが追加または削除された場合、コードを変更しないでください。ルールベースを変更するだけです。

パターンは、異なるオブジェクトが互いのAPIにアクセスしたり、タスクを配置するために通信する必要がある場合にのみ必要になります。

PS：考えてみてください-ファイアウォールがパケットを処理し、パケットを通過または拒否する（または変更する）とき-使用する設計パターンは何ですか？答えは上記のどれでもありません！