73

Chain of Responsibilityパターンを読んだところですが、デコレータよりもその使用を好むシナリオを想像するのに苦労しています。

どう思いますか？CoRにはニッチな用途がありますか?

4

10 に答える 10

15

鎖

リクエストを処理する機会を複数のオブジェクトに与えることで、リクエストの送信者と受信者を結び付けないようにします。受信オブジェクトをチェーンし、オブジェクトが処理するまでチェーンに沿ってリクエストを渡します。

対

デコレータ

オブジェクトに追加の責任を動的にアタッチします。デコレーターは、機能を拡張するためのサブクラス化に対する柔軟な代替手段を提供します。

物事が起こる順序の周りだと思います。それらをチェーンすると、チェーンに沿って が呼び出されます。デコレーターを使用すると、この順序は保証されず、追加の責任を追加できるだけです。

于 2009-04-14T14:49:43.063 に答える
14

Chain of Responsibilityは、特定の形式のDecoratorであると言えます。

于 2009-04-14T14:41:05.923 に答える
8

デコレーターは、オブジェクトに機能を追加する場合に使用されます。

COR は、多くのアクターの 1 つがオブジェクトに対してアクションを実行する可能性がある場合に使用されます。

タイプに基づいて、アクションを実行するために特定のデコレータが呼び出されます。一方、COR は、アクターの 1 人がアクションの完了を決定するまで、定義されたチェーンに沿ってオブジェクトを渡します。

COR は、さまざまなハンドラーへのエスカレーションに複数のレベルがある場合に使用できます。たとえば、会社に対する顧客の価値によって、電話が特定のレベルのサポートに進むかどうかが決まるコール センターなどです。

于 2009-04-14T14:50:25.450 に答える
4

さて、私は2つの状況を考えることができます:

  • コア オブジェクトがありません。つまり、すべてのレイヤー/フィルターを通過した後、リクエストをどう処理すればよいかわかりません。（リクエストがどこで終了するかをあまり気にしないインターセプターチェーンのような側面のようなもの）。
  • リクエストに対して前処理または後処理を選択的に適用する必要があります。デコレータのような一般的な拡張形式ではありません。つまり、フィルタは特定のリクエストを処理する場合と処理しない場合がありますが、デコレータを追加すると、常に何らかの機能でオブジェクトが強化されます。

今はこれ以上考えられません。このトピックについてもっと知りたいです。

于 2009-04-14T14:49:27.510 に答える
3

構造的な観点から、この 2 つのパターンは非常に似ていることに同意します。私の考えは、最終的な動作についてです。

リクエストを処理する CoR 要素の古典的な解釈では、チェーンが壊れます。

デコレータの要素がチェーンを壊すと、動作の基本部分が失われるため、デコレータの実装が間違っていることになります。そして、デコレーターの考え方は、基本的な動作が変更されていない場合に、新しい動作を透過的に追加することです。

于 2010-12-11T22:42:28.043 に答える
1
  1. キーワード'extends'-静的拡張。
  2. デコレータパターン-動的拡張。
  3. Chain Of Responsibilityパターン-一連の処理オブジェクトを使用してコマンドオブジェクトを処理するだけで、それらのオブジェクトはお互いを認識しません。
于 2012-01-24T11:38:43.967 に答える
1

ギャング・オブ・フォーの定義を読んだ後、私は本当の違いがあると確信していません. （便宜上含まれています）

  • デコレータ: 既存の責任と動作を変更するために、オブジェクトの動的なラッピングを可能にします
  • 責任の連鎖: 受信オブジェクトをリンクすることで、複数のオブジェクトに要求を処理する機会を与えます。

ウィキペディアはそれらを少し肉付けしていますが、その一部はちょっと恣意的です.

  • デコレータは通常、リンク リストとして実装されます。しかし、それはパターンの「一部」と見なすにはレベルが低すぎると思います。
  • 責任の連鎖リンクは、責任がある場合にのみデータを処理します。しかし、責任の決定とデータ処理はどちらも行動の一部です。デコレータはこれを簡単に行うことができます。
  • Decorator では、デリゲートを呼び出す必要があります。
  • 「純粋な」CoR リンクは、データを処理しない場合にのみデリゲートを呼び出す必要があります。

最初の 2 つの属性は、実際にはパターンを区別しません。2 番目の 2 つはそうしますが、Decorator と CoR が通常実装される方法では、これらの属性が強制されません。設計者は、チェーンを切断する Decorator や、データを処理した後にチェーンを継続する CoRLink を誰も作成しないことを望んでいます。

これらの属性を実際に実装するには、次のようなものが必要です。

強制デコレーター:

abstract class Decorated {

public Decorated delegate;

public final Object doIt(Object args) {
    Object returnVal = behavior(arg);
    if(delegate != null) returnVal = delegate.doit(returnVal);
    return returnVal;
}

protected abstract Object behavior(Object args); //base or subclass behavior
}

強制された一連の責任:

abstract class Link {

public Link delegate;

public final Object processIt(Obect args) {
    Object returnVal = args;
    if(isMyResponsibility) returnVal = processingBehavior(returnVal);
    else returnVal = delegate.processIt(returnVal);
    return returnVal;
}

protected abstract Boolean isMyResponsibility(Object args);

protected abstract Object processingBehavior(Object args);
}

(代わりに、他の誰かがあなたの設計を台無しにした場合に備えて、自分の責任を免除することだけが必要な場合は、javadoc に行を追加することもできますが、なぜそれを偶然に任せるのでしょうか?)

于 2014-03-18T19:09:24.007 に答える
0

この 2 つのパターンを適用する状況は異なると思います。ちなみに、デコレータパターンの場合、デコレータはラップしたコンポーネントを知っている必要があります。そして CoR の場合、異なるインターセプターはお互いのことを何も知ることができませんでした。

于 2011-11-05T16:51:36.247 に答える