カプセル化 (private と getter)

たった 1 行で壊せてしまう

フィールドをそのまま公開したクラスは、外から何でもできてしまいます。

class Player {
    public int hp = 100;
}

Player p = new Player();
p.hp = -50;

体力が -50 のプレイヤーが誕生しました。Java は止めません。文法としては何も間違っていない代入だからです。

厄介なのは、この行が Player の外に書かれていることです。クラスをいくら読み返しても原因は見つかりません。p.hp = ... と書ける場所がアプリ中に 20 か所あるなら、20 か所すべてが容疑者になります。

触らせない、と宣言する

フィールドの前に private を付けると、そのクラスの外からは触れなくなります。

class Player {
    private int hp = 100;
}

Player p = new Player();
p.hp = -50;   // hp has private access in Player

さっきまで通っていた行が、動かす前に、コンパイルの時点で止まります。「実行したら体力がマイナスになっていた」ではなく「そもそも書けない」に変わりました。

private は隠すための仕掛けというより、書き換えていい場所をクラスの中だけに閉じ込める 宣言だと考えてください。容疑者が 20 か所から 1 か所に減ります。

代わりに窓口を開ける

とはいえ、体力が一生変わらないゲームでは困ります。外から呼べるメソッドを用意して、そこだけを通ってもらいます。

class Player {
    private int hp = 100;

    public void damage(int n) {
        hp = hp - n;
        if (hp < 0) {
            hp = 0;
        }
    }

    public int getHp() {
        return hp;
    }
}

注目したいのは damage の中の if です。この 3 行を書ける場所ができたことが、private にした見返り です。フィールドを直接いじらせていたら、この判定を書くべき場所は呼び出し側 20 か所でした。いまは 1 か所しかありません。

getHp() のように値を返すだけのメソッドを getter と呼びます。読むのは自由、書き換えは決められた入口から、という形になりました。

解説

フィールドはまず private にして、外に出したいものだけ public なメソッドにする。この順番で書き始めると、あとから「誰がこの値を壊したのか」を探す時間がほとんど消えます。

やってみよう

右のエディタで safeAccount(int initial, int deposit) を完成させます。初期残高と入金額を受け取り、入金額が負のときはその入金をなかったことにして、最終的な残高を返します。damage の中の if と同じで、おかしな値を弾く判定を、値が入る直前の 1 か所に置く のがねらいです。

緑になったら、この判定をメソッドの外へ、つまり呼び出す側へ移したらどうなるかを考えてみてください。呼ぶたびに同じ if を書くことになり、1 か所書き忘れた瞬間に残高が壊れます。判定をどこに置くかは、好みではなく壊れやすさの問題です。

1. クラス名は Solution、メソッド名は safeAccount にすること
2. 引数は int initial と int deposit の 2 つ、戻り値の型は int にすること
3. deposit が 0 以上のときは initial + deposit を返し、deposit が負のときは initial をそのまま返すこと