この章を通してみてきたように、the Chain of Responsibility パターンでは、「機能チェーン」を構成するそれぞれのオブジェクト間で受け渡されるリクエストオブジェクトが中心的な役割を担っています。ですから、このリクエストオブジェクトの作成や変更時には十分な注意を払う必要があります。

また、the Chain of Responsibility パターンを採用することでプログラム実行時におけるハンドラーの入れ替えやシャッフルが可能となりますから、これを利用してチェーン全体のパフォーマンスを向上させることも可能となります。例えば前回の呼び出し時に使用されたハンドラーをチェーンの先頭に配置するようにすれば、より頻繁に使用されるハンドラーはチェーンの先頭付近に、使用頻度の低いハンドラーはチェーンの後半部分に並ぶようになるでしょう (ただしこの方法を採用できるのは、ハンドラーの実行順序を考慮しなくても済む場合のみです)。

しかし、ハンドラーの実行順序を考慮する必要がある場合であっても、このシリーズで学習したいくつかのアイデアを利用することでパフォーマンスを向上させることができる余地があります。例えば、特定のハンドラーに対するリクエストの処理結果についてはキャッシングを実行する、などです。

全く何の処理もなされないままのリクエストが素通りする、というのも気持ちが悪いですね。少なくとも、「機能チェーン」のいずれのハンドラーにも「引っ掛からなかった」リクエストが存在する、という警告を発するためのハンドラーをチェーンの一番最後に配置することも必要かもしれません; 例外処理構文でいうところの finally ステートメントの役割を果たすハンドラーです。

今回取り上げてきたミドルウェアアプリケーションの例では、「機能チェーン」に組み込んだ全てのハンドラーにリクエストが必ず流れるようにしていましたが、常にそうである必要はありません。「機能チェーン」の望む場所で処理を中断し return させることも可能です。

The Chain of Responsibility パターンはデータ処理を行うパイプラインを実装する一手段です。特に、あるリクエストを処理するためのハンドラーが複数存在し、実際にリクエストが来てみないとどのハンドラーで処理するのが最善であるのか判断できない、という問題に対しての解決策の１つを提供してくれるものです。