3

顧客がバウチャーを使用して購入の割引を受けることができるシステムを実装しています。特定の購入にバウチャーを使用できるかどうかは、いくつかの状況によって異なります。

例えば：

  • 適切なバウチャー コード - コードは正しいですか?
  • 有効範囲 - バウチャーはまだ有効ですか?
  • バウチャーは購入の種類で使用できますか?
  • 組み合わせ可能 - バウチャーを他のバウチャーと組み合わせることはできますか?
  • もっとたくさん...

確認する必要がある、より複雑な制限もいくつかあります。1 つ以上の制限が満たされていない場合、お客様はバウチャーを使用できません。このバウチャーを使用できない理由を説明して、失敗したことを伝えたいと思います。例:

「有効期限が切れているため、このバウチャーはご利用いただけません。」

私の質問は次のとおりです。チェックをどのように実装しますか?
それぞれの制限を独自のクラスに実装し、それらを連鎖させて例外をスローしますか? (ここでの問題、複数の同一のデータベース クエリが実行される可能性があります) 1 つのメソッドですべての制限を実装しますか? (本当に、なぜ?) 一般に、アクションに複雑な制限が適用された場合に、失敗の詳細についてクライアントに通知する必要があるメカニズムをどのように実装しますか?

ありがとう、

4

3 に答える 3

2

個人的には、1つの方法でチェックを実装します。バウチャーが入り、エラーメッセージが出ます（もしあれば）。

これにより、すべてのコードがそのメソッドの背後に隠され、メンテナンスが容易になります。何かがうまくいかないかどうかをチェックするための1つの場所、新しいものを追加するときに変更するための1つの場所など。

多数のテストについて話している場合は、メソッドをクラスに変更するよりも（ただし、複雑さが全体に広がることなく、責任は1か所にあります）。

ちょうど私の2セント。

于 2010-01-26T13:57:06.080 に答える
0

私は最近、ワンステップのチェックアウトページを使用して注文をチェックする同様の問題に対処しました。結局、最初に遭遇した問題を説明する文字列よりも、関連するすべての「問題」の配列を生成する方がはるかに便利であることがわかりました（コードやメッセージの表示などを含む単純なクラスでこれらをラップしました）。

これは、関連する問題の配列を返す単一のチェッカーメソッドで機能します。メインのチェッカーメソッドは、より具体的なチェッカーメソッドを呼び出して配列を構築します。他のチェックがすでに失敗している場合は、一部のチェックをスキップすることを選択できます。

于 2010-01-26T23:55:15.647 に答える
0

意図を抽象化して、それがどのように実装されているか、またはソースコードがどのように構成されているかが問題にならないようにします。基本的なレベルでは、失敗の説明のコレクションを生成するチェッカーのコレクションがあります。

疑似コードは基本的に次のようになります。

let reasons be a new, empty collection of failure reasons 
let checkers be the list of relevant checkers

for each checker in checkers
    if checker passes, continue
    if checker fails, add explanation to reasons

if number of reasons is zero, 
    voucher is valid, success
if number of reasons > zero, 
    the voucher is invalid, format each element in reasons for display to the user

このロジックが整っていれば、リスト内のコードのこの部分によってチェッカーを取得できる限り、チェッカーがどのように構成されていてもかまいません。1 つのメソッドに多くのチェックを行うことができ、多くの理由が追加される可能性があります。チェッカーのリストにそれぞれのインスタンスを 1 つずつ含めて、多くのクラスを作成できます。重要なのは、実際のチェッカーがこのロジックから切り離されており、いつでも異なるチェッカーを使用できることです (ビジネス ルールの変更や、異なる地域での異なるルールを考えてみてください)。

言語によっては、少なくとも、チェッカーに使用される型を抽象化する必要があります。

それから始めましょう。同一のデータベース クエリが見つかった場合は、チェッカーのコレクションを実行するためのキャッシュの検討を開始します。

チェッカーがソース レベルでどのように構成されているかについては、問題ではありません。抽象化のみが行います。隠れることができるレベルの抽象化を提供すると、詳細はかなり柔軟になります。

長所：

  • チェックを実行するビットは、実際の具体的なチェック (ビジネス ルールに基づいて変更される可能性があります) を気にしません。
  • チェッカーは、1 つのソース ファイルでまとめて定義するか、他のスキームに基づいて分散させるなど、自由に編成できます。また、テスト用に単一のチェッカーを自由に分離することもできます。
  • コレクションときれいな書式設定は、チェックの種類や数に関係なく、一度だけ実装する必要があります。

短所：

  • 抽象化を適切に設計するには、事前に時間がかかります。これはおそらく後で報われるでしょう。
  • 間接的なレイヤーがあり、理解しにくく、実際に行われているチェックを追跡するのが難しくなる場合があります。柔軟性は、理解の妨げになります。これらは、シナリオで考慮する必要があるものです。私の意見では、バウチャーのルールは時間の経過とともに変化する可能性があり、ここでの抽象化は理解するのが難しくないので、価値があると言えます.

Java で例を書くのに時間を費やしましたが、実際にはあまり役に立ちませんでした。抽象化の観点から考えようとすると、実際のメカニズムはそれほど重要ではなくなります。

于 2010-01-26T22:43:56.653 に答える