開発者ブログ受託開発担当のRyuです。デザインパターンは数ありますが、私が学んだときどうしても用途がよくわからないパターンがいくつかありました。Responsibilityパターンについてです。Responsibilityパターンはチェーンを使用して、各関数に処理の可否を委ねるものです。このパターンを知ったとき最初に持った感想は、上位部分で分岐させてしまえばいいのでは?というものです。関数に判断させても、呼び出しのオーバヘッド分遅くなるだけだろうと。そんな中、以下のようなコードに出会いました。Method1には存在しないMethodC(hoge);break;}}似たような分岐が存在しています。Method4と増えていき条件Aと条件Cのみ、条件Dが追加されるなどの可能性があったので、もう少し扱いやすい形にしようと考えました。true;}結果上記のような形に。重複していた条件部分を外に出して、変更に少し強くなりました。Method4と増えていっても扱いやすい形にもなりました。Method2だけを見た場合、何をしているのか少し見通しが悪くなった感じがします。Responsibilityパターンなのではないかと。これまで分岐はなるべく上位に、とにかく少なくと考えていましたが、分岐自体をバラバラにしてしまうことで分岐の数は増えても保守性の高いものを作成できることに気づかされました。Responsibilityパターンがとても好きになりました。開発者ブログの内容は無保証です。製品のユーザサポート対象ではありません。圧力に屈してマテリアルデザイン勉強中。technology.。