「状態管理用の変数をインスタンスに持たせるなこのタコって話」という記事のStateパターンを適用したときのリファクタリングのステップが気になって。

内容の批判とかではなくて、自分が気になったことで、記事にするのもどうかなって思ってたのですが、サンプルコードを書いちゃったので、折角なので書きおきします。 状態管理用の変数をインスタンスに持たせるなこのタコって話 - life.should be_happy # => 1 examples, ? failures という記事がホットエントリに出ていて、すごく面白いです。 その中で 「Stateパターンを使おう」というところでリファクタリングのステップが大きいなーって感じて、30分ぐらい考えてしまったんです。 Stateパターンってのをよく知っていれば、書き換えることは難しくないのですが、丁寧にコミットすることを考えたとき、どういうリファクタリングのステップにすればいいのかな、と。 リファクタリングは極力小さなステップで行うほうが良いです。いきなりがっつりやるためにはテストコードがほぼ必須になります。 あったとしても小さいほうがうごかなくなって悩む時間が減ります。 ということで、「リファクタリング飛躍」 に該当する部分は、player_02.rb から player_03.rb への変化する部分になります。 リファクタリングのステップが大きすぎることを「リファクタリング飛躍」と個人的に呼びたいです。 例 1 クラスごとに分かれる処理を case でまとめておく https://gist.github.com/eiel/4748209 ポイントだけ、抜粋します。 元のコードは: def move(direction) case @moving_mode when MOVING_MODE::NORMAL x_speed = 10 # かにモードとの整合性のために y_speed = 10 # 無駄な変更が加えられている when MOVING_MODE::FAST x_speed = 20 # FASTモードにも！ y_speed = 20 when MOVING_MODE::KANI x_speed = 40 y_speed = 5 end case direction when :up