問題タブ [chain-of-responsibility]

すべてのリクエストは、通過するチェーンとして作成されたクラスと同様のグループで定義されたインターセプターを介して送信されます。インターセプターとChainofResponsibilityの違いは何ですか？

チェーンに渡されるオブジェクトとしてHashMapを使用し、ハンドラーによって新しいコンテンツが追加される可能性があるCoRパターンの実装例を見てきました。以下のコードの概要：

contextハンドラーは、コードを繰り返さずにハンドラーをフォローすることで使用できる新しい情報でを拡張できるため、使いたくなります。一方、ハンドラーは相互に依存するようになります。ハンドラーはまだ緩く結合されていますが、それでも、ハンドラーの順序はますます重要になります。

このコードは臭いですか？コンテキストオブジェクトに新しい情報を追加せずにCoRパターンを使用できないことがわかった場合、そのような場合に使用する適切なパターンは何ですか？

私はデータ マイナーなので、生データをさまざまな方法で変換して、予測モデルによる消費を可能にすることに多くの時間を費やしています。たとえば、特定の形式でファイルを読み取り、トークン化し、グラム化し、何らかの数値表現に射影します。何年にもわたって、考えられるほとんどのデータ処理タスクを実行するための豊富なメソッドのセットを開発してきましたが、最も基本的な方法を除いて、これらのコンポーネントを構成する良い方法はありません。通常、私が行うことはたくさんあります。特定のタスクに依存するソース コード内の特定のメソッドへの呼び出し。私は今、自分のライブラリをより良いものにリファクタリングしようとしていますが、これが何であるかはよくわかりません.

私の現在の考えは、関数オブジェクトのリストを持ち、それぞれがいくつかのメソッド (たとえば、operate( ... ) ) を定義し、順番に呼び出され、それぞれが参照によってデータフローの内容を処理するか、出力を消費することです。前の関数オブジェクト。これは私が望むものに近いですが、入力と出力されるデータの型が異なるため、ジェネリックを使用することは非常に困難になります。上記の例を使用するには、次のようなデータを処理するこの「パイプライン」を介して何かを渡したいと思います:

これは単純な例ですが、このようなコンポーネントが数百個あり、それらをデータ フローに追加したいとします。これは、設定が簡単な要件を満たしています。いくつかの yaml ファイルを読み取ってこれを構築するパイプライン ファクトリを簡単に構築できます。しかし、コンポーネントの設計パターンにしばらく悩まされていましたか? 適切なインターフェースはどのように見えますか? ここで物事を行う唯一の簡単な方法は、オブジェクトを渡して、本質的にオブジェクトを廃止し（またはオブジェクトをメンバー変数として持つコンテキストオブジェクトを渡して）、入力時の互換性をチェックし、ランタイム例外をスローすることです。 . どちらのオプションも同じように悪いようです。しかし、私はここで本当に素晴らしく柔軟なシステムに近づいているように感じます. これをフェンス越しに押すのを手伝ってくれませんか？

次のコードを書くと：

次に、コード分析はこれに次のフラグを立てます。

警告1CA2000：Microsoft.Reliability：メソッド'ServiceUser.Execute（）'で、オブジェクト'stream'へのすべての参照がスコープ外になる前にSystem.IDisposable.Disposeを呼び出します。C：\ Dev \ VS.NET \ DisposeTest \ DisposeTest \ ServiceUser.cs 14 DisposeTest

ただし、ファクトリパターンを作成した場合でも、オブジェクトを破棄する必要がある場合がありますが、FxCop /CodeAnalysisは文句を言いません。むしろ、それを呼び出すコードではなく、ファクトリメソッドについて文句を言います。 （ファクトリメソッドについて不満を言った例があったと思いますが、ここに投稿したものはそうではないので、それを打ち消しました）

たとえば、属性を使用して、IDisposableオブジェクトの責任をファクトリメソッドから呼び出し元に移動する方法はありますか？

このコードを取る：

この場合、警告はありません。FxCOP/CAに元の方法についてまだ文句を言ってもらいたいのですが。そのオブジェクトを処理するのはまだ私の責任です。

これについてFxCOP/CAに伝える方法はありますか？たとえば、私は最近、ReSharperが提供する注釈属性に挑戦し、分析エンジンの情報を伝えるために、他の方法では理解できないようにしました。

だから私はこのようなものを想像します：

それとも、この設計はかなり離れていますか？

以下の問題で悩んでいます。一連の関数オブジェクトがあり、それぞれがJavaのジェネリック型引数を介して定義された独自の入力型と出力型を持っています。生データが最初の関数に入力され、次のオブジェクトの入力型である出力型に変換されるように、これらをチェーンに配置したいと思います。もちろん、これはハードコードするのは簡単ですが、コードを新しい関数オブジェクトにプラグインできるようにしたいと思います。型引数 (最終的な出力型のみ) を省略すると、次のようになります。

ここでは、データに対する反復子が関数オブジェクト間で渡され、コンテキストは Context である必要があります。次の種類のパイプをプラグ可能に保ち、タイプの安全性を維持する方法はありますか?

編集：わかりやすくするために、一連の関数オブジェクト、パイプがあります。それぞれが特定の型を入力として受け取り、別の型を出力します。(実際には、これらの型のイテレータ) これらは連鎖されます。たとえば、Pipe<A,B> -> Pipe<B,C> -> Pipe<C,D> -> ...1 つのパイプの出力が次のパイプの入力型になるようにします。ここには、タイプ A の反復子を出力するソースと、タイプ (過去のパイプの出力) を受け入れるシンクもあります。これは物事をより明確にしますか？問題は、入力と出力の型の互換性に大きく依存しているため、これを保証する方法はあるのでしょうか?

関数オブジェクトをパイプラインに挿入するときが、型の安全性を確保するのに最適な時期かもしれないと考え始めていますが、これを行う方法がわかりません。

編集 2: 現在、以下のような関数オブジェクトの adder メソッドがあります。

最初の型パラメーターが現在のパイプの「終了」と同じかどうかを確認し、そうでない場合は例外をスローしますか? ここでコンパイル時の安全性を確保する良い方法があるとは思いません。現在のパイプの「終了」は、入力パイプの 2 番目のタイプのパラメーターに設定できます。ジェネリックでこれを行う方法が思い浮かびません。また、クラス情報を渡すのは非常に恐ろしいようです。

アイデアは、さまざまな MIME タイプを処理する必要がある COM インターフェイスの主要な実装があるということです (MIME は単なる例です)。主な実装では、顧客サイトにあると予想されるいくつかの一般的な MIME タイプを処理します。

新しい MIME タイプを処理するには、同じ COM インターフェイスを実装する必要がありますが、その新しい MIME タイプに対してのみ実装する必要があります (これを拡張 COM オブジェクトと呼びましょう)。クライアントは、MIME タイプを処理する拡張 COM オブジェクトを最初に呼び出します。MIME タイプが認識されない場合は、プライマリ COM オブジェクトを呼び出します。複数の拡張 COM 実装である可能性があると想定できます。したがって、責任の連鎖があります。

COM の責任連鎖は可能ですか? 実用的ですか？

ありがとう

次のように「リンク切れ」の問題に対処しながら、責任の連鎖パターンを実装したいと思います。

十分に一般的なアプローチのようです。しかし、保護された抽象メソッドでこれをどのようにテストできるのでしょうか? これを処理する方法は次のようです。

1. Handler抽象メソッドを実装する のテスト専用サブクラスを実装します。これは、テストのメンテナンスには悪いようです。
2. 抽象メソッドの可視性をパブリックに変更しますが、テストに対応するために SUT を変更する必要はありません。
3. 抽象クラスは、単体テストを必要としないほど十分に単純であると見なします。んー。
4. handleRequest1 つ以上の具象サブクラスでメソッドの単体テストを実装します。しかし、これはテストを編成する賢明な方法とは思えません。
5. モックオブジェクトを使用する方法はありますか? Mockito を試してみましたが、保護された可視性を回避できないようです。

この種のテストの問題は、設計が間違っていることを意味し、継承ではなく構成を使用することをお勧めします[ 1 ]。私は今これを試していますが、このパターンの推奨される実装にこの問題があるのは奇妙に思えますが、単体テストに関するアドバイスは見つかりません。

更新: 示されているように、抽象クラスを依存関係の反転に置き換えました。これは、Mockito を使用して簡単にテストできるようになりました。まだ責任の連鎖のように見えます...何か足りないのですか?

誰かが責任の連鎖パターンの簡単な説明を提供できますか？wikiの記事は少し紛らわしいと思いました。

手順では、多くのif-else条件を使用して列の値を決定する必要があります。スクリプトはで始まります

FOR rec IN（SELECT ....）LOOP Begin

そして、 recサブレコードが各反復で取得できる多くの異なる値を決定します。場合によっては、変数の割り当てが2つまたは3つしかない場合もあれば、別のプロシージャの実行やINSERT操作の実行が含まれる場合もあります。

これは、ループのSELECTステートメントの結果として多くのレコードが存在するパフォーマンスの観点からの意思決定に最適なアプローチですか、それともより良い代替手段がある可能性がありますか？この手順を作成する際にChain-of-responsibilityパターンを採用するとどうなりますか？このアプローチはパフォーマンスを向上させますか、それとも事態をさらに悪化させますか？

よろしく。

私は基本的に責任の連鎖パターンのバリエーションであるタスクのパイプラインを持っています。

パイプラインのタスクは次のようになります

..そして私のプロセッサは次のようになります

私の具体的な実装は次のようになります。

..そして私のタスクは次のようになります：

Tは異なるインスタンスである可能性がありますが、一般的なコントラクトに拘束されます。タスクの1つは、着信オブジェクトを完全に異なるオブジェクトにマッピングし、そこからそのインスタンスを転送することです。

ご覧のとおり、パイプラインですべてのタスクを実行しています。これを次のように変更します。

• 次のタスクのメソッドの入力はExecute、以前に実行されたタスクからのものである必要があります。
• タスクが失敗した場合CanExecute、パイプラインはタスクの処理を停止する必要があります。

これを手に入れるのを手伝ってくれませんか。また、この目的のためにコードが異なる構造になることを期待しますか？