Tidy First? ―個人で実践する経験主義的ソフトウェア設計

12章ヘルパーを抽出する

ルーチン内に、明確な目的を持ち、他のコードとの相互作用が限られているコードブロックがある。これをヘルパールーチンとして抽出しよう。（ルーチンがどのように機能するかではなく）目的に合わせてルーチンに名前をつけよう。

リファクタリングに詳しい人なら、この整頓を「メソッドの抽出」と考えるだろう。この整頓やリファクタリングを実行するには、自動リファクタリングがないと厄介だ。だから自動リファクタリングが実行できる環境にいるべきだ。なにしろ21世紀なのだ。

ヘルパー抽出の特別なケースをいくつか紹介しよう。1つは、大きなルーチン内の数行を変更する必要がある場合だ。その行をヘルパーとして抽出し、ヘルパー内の行だけを変更する。そして、それが理にかなっているなら、ヘルパーを呼び出し元のルーチンにインライン化する（たいていは、そのヘルパーに愛着が湧いて、そのまま使い続けることになる）。たとえば、このようなコードがあるとする。

routine()
    ...変更しない部分...
    ...変更する部分...
    ...変更しない部分...

こうなる。

helper()
    ...変更する部分...

routine()
    ...変更しない部分...
    helper()
    ...変更しない部分...

（この先を読んでいれば、このような抽出は凝集、つまり、まとまりのある要素を作り出すことだとわかるだろう。まだ先を読んでいなくても心配ない。すぐにわかる）。

もう1つのヘルパー抽出のケースは、時間的な結合を表現する場合だ（a()はb()の前に呼び出される必要がある）。

たとえばこんなコードがある。

    foo.a()
    foo.b()

よく、こうする。

ab()
    a()
    b()

ヘルパーを使い続ける理由は何も愛着だけではない。新しいヘルパーを作ってから数時間後、あるいは数分後に使いたくなることがよくある。インターフェイスは問題を考える道具になる。新しいインターフェイスは、私たちがより抽象的に考え、デザインボキャブラリーに言葉を加える準備ができたときに現れる。 ...