良いコ-ドへの道―普通のプログラマのためのステップアップガイド

最終回 配列/コレクションを利用した抽象化―その3 Step2:可読性を高めるためのメソッドの抽出

この記事を読むのに必要な時間:およそ 1.5 分

Step2:可読性を高めるためのメソッドの抽出

ファイル取得の部分をメソッドに切り出してみたー。getFilesというメソッドを作成しました(リスト3)。


リスト3 Step2Action

@Path("/")
public class Step2Action extends Action {
    ...
    public ActionResult step2() {
        foodFiles = getFiles("/images/food");
        animalFiles = getFiles("/images/animal");
        landscapeFiles = getFiles("/images/landscape");
        foodSize = FileUtil.sizeOfFiles(foodFiles);
        animalSize = FileUtil.sizeOfFiles(animalFiles);
        landscapeSize = FileUtil.sizeOfFiles(landscapeFiles);
        return new Forward("step2.jsp");
    }

    private File[] getFiles(String path) {                ┓
        File[] files = new File(context.getRealPath(path))
                           .listFiles();                  |
        return files;                                     |
    }                                                     ┛①
}

確かに何をやっているのかわかりやすく読みやすくなったっすね。ついでに,sizeOfFilesメソッドはフィールド変数にアクセスしていなかったので,staticメソッドにしちゃいました注10)。あと,特にこの画面独特のメソッドでもないから,ユーティリティクラスに移動させちゃったよリスト4)。これでどこからでもsizeOfFilesメソッドが利用できるっす。

リスト4 FileUtil

public class FileUtil {
    public static long sizeOfFiles(File[] files) {
        long totalSize = 0;
        for (File file : files) {
            totalSize += file.length();
        }
        return totalSize;
    }
}

かなりすっきりしてきたのう。ほかに気になるところはあるかのう?


ディレクトリの数が3つ固定という前提で作られているのが最初から気になっていたっす。4つに増えたらどうなるっすか?


たとえば,「fish」というディレクトリが増えたら,「fishFiles」「fishSize」という2つのフィールドが追加されて,JSP側もほかのディレクトリと同じようなコードが追加されると思います。

ここはいよいよ抽象化するしかないんじゃない??達人プログラマ,決断をお願いします!!


ふぉっふぉっふぉっ,そうじゃのう。抽象化して処理したほうがいいかのう。ディレクトリが増えることがあり得ないのであれば,このままでもよいのじゃが,ここでは「増える可能性も50%ぐらいある」という前提で話を進めるぞい。

じゃあ,俺が抽象化してまとめるっすよ!!


まあ,待て待て。じっくりとコードを見て,フォースを感じるのじゃ。抽象化の前にやれることがあるはずじゃぞ。


私が気になるのは「foodFiles/foolSize」「animal Files/animalSize」のように2つセットでフィールドが増えていく点です。うまく言えませんが,なんだかモヤモヤする感じです。

グッドポイント。抽象化の前にデータ構造の整理をしておくぞ。「ペアで管理すべき変数」が出てきたら,不吉な匂いじゃ。ほとんどの場合,それらの変数は「1つのオブジェクト」にまとめることができるはずじゃ。

そうなんですね! ちょっとやってみます!!


注10)
インスタンスメソッドをstaticメソッドにする利点については,本紙Vol.46の本連載第3回「スコープを意識したプログラミング」インスタンスメソッドの可視性の節を参照してください。

著者プロフィール

縣俊貴(あがたとしたか)

学生時代にMSXで制限された環境でのプログラミングの楽しさを学ぶ。以来,オープンソースのWiki実装「MobWiki」の開発や受託開発などを経て,現在はプロジェクト管理ツール「Backlog」,ドローツール「Cacoo」など,コラボレーション型のWebサービスの企画と製品開発を行う。また,Webアプリケーションフレームワーク「Cubby」のコミッタを務める。福岡在住。株式会社ヌーラボ所属。

ブログ :http://d.hatena.ne.jp/agt

Twitter:@agata

コメント

コメントの記入