Strategyパターン

ちょっともにょることもあるけれど、大分ましになってきました。 前の記事の追記みたいなことが好き勝手に出来るから、loose leafはよい感じ。

一日/１個(転送速度)な感じです。

Strategyパターンは、ソートや選択のアルゴリズムを入れ替えたり複数用意したいとき、
ソートの結果の入出力などのインタフェースをスーパークラス(Strategy)に書いておいて、 サブクラス(ConcreteStrategy)にそれぞれのソートや選択のアルゴリズムを書くようにすると、 元のクラスを利用するクラス(Context)は書き換えなくていいね、 というものっぽいです。

Strategyパターンらしいアルゴリズムが云々と言ったことはあまりしたことないのですが、 重いページの高速化をしたいのだけどまともに1からテストを作るのが大変だったことがあり、 ソートだけする部分とか、表示だけ作る部分とかに分割して括り出して、 元のメソッドと同じ結果を返す事を保証するテスト書いてから軽い方に置き換える、 というのはやったことがあります。

なんていうか、レビュー相手が安心するんですよね。 前と結果同じだよ！って見せると。

こういうとき、Strategy役は頭の中にあるだけなんですが、 もう少し規模が大きくなりそうな時ははっきりと用意した方がやりやすいかもですね。

テストのクラスはContextクラス、とも言えるので、実はいろんな人に取ってなじみが深いパターンなのではないでしょうか。