私はかなり長い間デザインパターンを使用しており、それを「責任の連鎖パターン」と呼んだり参照したりしてきましたが、今では違いがあることに気づきました。そうするのは適切ではないかもしれません。したがって、私の質問は 1、「次はこのパターンのインスタンスですか、それとも別の名前にする必要がありますか?」、および 2、「従来の方法を好む理由はありますか?」です。
ソフトウェアを開発するときは、次のパターンをよく使用します。functorを定義するインターフェースがあります。このようなものです。
interface FooBar{
boolean isFooBar( Object o );
}
これらは通常、検索、フィルタリング、または処理クラスです。通常はComparatorのようなものです。通常、実装方法は機能的です (つまり、副作用がありません)。最終的に、次のようなインターフェイスの実装を作成していることに気付きました。
class FooBarChain implements FooBar{
FooBar[] foobars;
FooBarChain( FooBar... fubars ){
foobars = fubars;
}
boolean isFooBar( Object o ){
for( FooBar f : foobars )
if( f.isFooBar( o ) )
return true;
return false;
}
}
常にブール値であるとは限りません-私はこのパターンを変更可能なオブジェクトでも使用しました-しかし、短絡条件が常にあります(たとえば、trueを返す、文字列が空の文字列である、フラグが設定されるなど)。
基本クラスからの継承の問題が実装の詳細であることを考慮して、これまでは一般的にこれを「責任の連鎖」パターンと呼んでいました。しかし、今日、重要な違いに気付きました。チェーンに沿ったオブジェクトは、チェーンの残りの部分を中断することはできません。実装が「これは false であり、どの条件でも false になることを保証できます」と言う方法はありません (nb: でのみ短絡true
)。
では、これは責任連鎖パターン以外の何かと呼ぶべきでしょうか? インスタンスにメッセージを渡す従来のアプローチよりもこのアプローチを使用する場合に考慮すべき懸念事項や問題はありますか。