12

私は現在のプロジェクトで責任の連鎖パターンを頻繁に使用していることに気づきました (私にとっては 3 回が多い)。解決策について少し熱狂しすぎたのではないかと思っています。具体的には、Apache Commonsチェーン プロジェクトを使用しています。そのため、これまでのところ、アプリ ロジックの複雑で交換可能な多数の部分が、よりまとまりのある組織化された全体に簡素化されていることに非常に感銘を受けました。しかし、このプロジェクトに参加した新しい人々の中には、「それを理解する」のに苦労しているように見える人もいます。それについてあなたの経験は何ですか？その実装でどのような問題に遭遇しましたか?

これまでのところ、私が気づいた唯一の問題は、閉じる必要があるオブジェクトを処理しようとしているときです。これらのオブジェクトを Context クラスに格納すると、チェーンの実行が完了したときに苦労します。コマンドの代わりにフィルターを使用してこれを回避できましたが、close ステートメントはオブジェクトがインスタンス化された場所から非常に離れていることが多いため、少し直感的ではないようです。

いずれにせよ、このパターンについて私より経験のある開発者の意見を聞きたいです。

前もって感謝します。

4

2 に答える 2

9

特定の問題 (フレームワーク コードなど) ではうまく機能するが、特定の問題ではあまり機能しないと言いたくなる。フレームワークは他の人が使用できるように作成されており、クライアントに完全な実装の自由を与えたいと考えています。問題を解決するために何をしようとしているのかを正確に把握したら、他の解決策の方が優れていると思います。

Chain of Responsibility パターンの危険性は、Blackboard パターンの場合とほぼ同じです。最終目標を達成する上でほとんど価値を提供しない多くの抽象化を作成してしまうのは非常に簡単です。コマンド オブジェクトと処理オブジェクトは、アプリケーションのロジックを処理チェーンの背後に隠しているだけであり、最も重要なコードがある場所のすぐ前に配置するのではありません。処理チェーンを抽象化せずに完全な処理チェーンを表すメソッド (または複数のメソッド) をプログラムするだけで、これを理解し維持するのがはるかに簡単になります。処理チェーンは、アプリケーションのビジネス ロジックを実際に隠すことができます。ビジネス コードよりも技術的な成果物を優先していると思います。

したがって、基本的には、非常に簡単に読み取れる非常に単純なアプリケーション コードであった可能性があるものを、より抽象的な処理チェーンに置き換えます。あなたはメタプログラミングをしています。個人的には、私はもうメタプログラミングを一切行っていないので、メタプログラミングを嫌う同僚に同意する傾向があります. ;)

于 2009-01-27T10:27:24.690 に答える
3

一般に、コストよりも多くのメリットが得られる場合は、特定のデザイン パターンを使用する価値があると言っても過言ではありません。すべてのパターンは、コードに余分なレベルの間接性を導入するため、特にチームの若手メンバーにとっては、従うのがより困難になります。とはいえ、処理を実行するクラスが事前にわからない場合 (つまり、チェーン内にある場合)、またはこれらのクラスを別の方法で再利用する場合、責任の連鎖パターンは間違いなく役立つと思います。コンテキスト、さまざまなシナリオでさまざまなチェーンを作成するなど。

一般に、ソリューションを過度に設計することはかなり悪いと思います (あなたが言ったように、新しい人はそれを理解するのに苦労するため) が、設計パターンが非常に役立つ場合もあります。

于 2009-01-27T10:44:53.733 に答える