web-dev-qa-db-ja.com

最適なOOP一連の操作の設計パターン

私はアプリケーションに取り組んでおり、そのモジュールは次の財務操作を順番に実行します:

ユーザーが特定の金額を自分の銀行口座に送金するように要求すると、次のようになります。

  1. トランザクションが発生するかどうかを確認しますか? (一定期間のみ取引可能)
  2. ユーザーが最小金額の引き出しを要求しているかどうかを確認します
  3. ユーザーがデフォルトのアカウントを持っているかどうかを確認します

上記のすべてのアクションの結果がログに記録されます。

上記のすべての条件が満たされる場合、トランザクションが実行されます。将来的には、いくつかのチェックが追加される可能性があります。

上記のケースに最適なオブジェクト指向のデザインパターンはどれですか。

11
kumar

探しているのは Chain of Responsibility のようです。この場合、次のクラスを使用できます。

  • TransactionValidatorBase抽象基本クラス
  • TransactionTimeValidator
  • TransactionAmountValidator
  • TransactionAccountValidator

これはチェーンされて、指定した多くのルールが適用されます。

さらに読む

13
p.s.w.g

ここでの正しいパターンは、実際にはコンテキストに依存します。固執する特定のパターンを選択する前に、これらの質問に対する答えを見つけようとします。

  • 実行時に(1,2,3)チェックのさまざまな組み合わせを作成する必要がありますか?
  • アクションを実行するために同じ変数が必要ですか、それとも大きく異なりますか?
  • エラーメッセージはどの程度正確でなければなりませんか?
  • 失敗した場合、ユーザーは常に(1)の最初のステップから再試行しますか?
  • 並行性はどのように処理されますか?
  • 各メソッドはリクエストに何かを追加したり、単に検証したりしますか? (デフォルトのアカウントIDと言いますか?)

直感に基づいて、エラーコードの集約パラメーターを持つプレーンメソッドとしてコーディングします。

public void DoTransaction(IErrorAgregator error, TransactionRequest request)
{
    if(!IsTransactionInCertainTimePeriod(request, error)) return;
    if(!IsTransactionAmountInUserBounds(request, error)) return;
    if(!UserHaveDefaultAccount(request, error)) return;
    bankingTransactor.PerformTransaction(request);
}

DoTransactionを "ITransactionValidationStragegy"インターフェイスに配置して、検証ボイラープレートコードを含むレイヤーのスーパータイプを作成することをお勧めします。

ただし、この設計では、検証ロジックはコンパイル時に決定されると想定しています。

2
Valera Kolupaev

@ p.s.w.gの回答で説明されているように、入力シーケンスを変更せずに、一連のステップで主に検証作業を行っている場合は、入力を変更することなく、「Chain of Responsibility」パターンを考えます。

しかし、あなたの質問はもう少し一般的であるため、「パイプライン処理」も追加したいと思います。これにより、ステップは次のステップの入力になる出力を生成します(したがって、元の入力を変更します)。 。

これに関する2つの記事を次に示します。
Martin Fowlerによるパイプラインコレクション
パターンに関するより理論的な議論

1
julio.g

ここではすでにパターンについて説明していますが、使用しているフレームワークに基づいて、アプリケーションで同じように使用する方法を検討することをお勧めします。

たとえば、実行する検証は、時間の経過とともに変化し続ける可能性が高いです(トランザクションを1日10に制限する新しい検証を将来追加したい場合があります)。また、実際のビジネスサービスまたは統合コードが実行される前に検証を実行したくない場合もあります。検証を構成可能な検証として追加できると便利です。

Strutsを使用している場合は、インターセプターを使用することをお勧めします。春の場合、依存関係としての豆の注入により、柔軟性が向上します。私の提案は、パターン/イディオムだけでなく、アプリケーションを構築するために使用するフレームワークを見て、未来的な観点から要件にどのように最適に適合できるかを確認することです。

0
Arun