java - 責任の連鎖 [GoF] の欠点

Question

販売注文を処理するソリューションを構築する必要があります。処理は連続して行われます。各ステップは特定のタスクを処理します。クライアントに信用があるかどうか、必要なアイテムの在庫があるかどうかなどを確認します。

責任パターンの連鎖を使用することを考えました。

私はこの古いが非常に貴重な記事を見つけました。CoR と Template パターンを比較することから始めます。結合については気にしていないので、どちらも機能しているようです。

注意すべき欠点 (または落とし穴など) はありますか?

Answer 1

これはあまり適していません。責任の連鎖パターンは、前の手順では処理できないタスクを委任するためのものです。

あなたの場合、CoRが実際には適用されないように、すべてのステップを適用する必要があります。

ここで本当に必要なのは、jBPMのようなある種のビジネス プロセス エンジンです。プロセス エンジンは、このような状況を正確に処理するように設計されており、手動ソリューションでは実装が難しい多くの機能を提供します。たとえば、次のようなものです。

• データベースに持続する長時間実行プロセスを持つ機能。サーバーを再起動しなければならなかったために失われた順序をデバッグしようとするのは面白くありません....
• メッセージ キューで外部イベントを待機する機能 (リモート システムからの確認の取得など)。いくつかの単純なケースではこれは必要ないかもしれませんが、外部サプライヤーと統合している場合は不可欠になります。
• 例外的な条件の処理とプロセスのロールバック/補償
• イベントのログとレポート

基本的に、これは車輪の再発明に反対することをお勧めする状況の 1 つです.....

Answer 2

これ以上 mikera に同意することはできません。

1) COR は適していません - なぜですか? mikeraが言ったことに加えて、あなたの問題定義は構造について語っています。つまり、一連の操作（クレジットの確認、在庫の確認など）がありますが、行動パターンである責任の連鎖を選択しました。何かがおかしいと感じます。

2) 車輪を発明しないでください。特に、販売処理などの金融商品について話している場合はなおさらです。

とはいえ、まったく別の話ですが、Facade デザイン パターンを使用して、サブシステムをカプセル化する統一されたインターフェイスを提示できます。ここの例には、問題と同じビジネス ケースがあります。