カプセル化 (private と getter)
たった 1 行で壊せてしまう
フィールドをそのまま公開したクラスは、外から何でもできてしまいます。
Java
class Player {
public int hp = 100;
}
Player p = new Player();
p.hp = -50;体力が -50 のプレイヤーが誕生しました。Java は止めません。文法としては何も間違っていない代入だからです。
厄介なのは、この行が Player の外に書かれていることです。クラスをいくら読み返しても原因は見つかりません。p.hp = ... と書ける場所がアプリ中に 20 か所あるなら、20 か所すべてが容疑者になります。
触らせない、と宣言する
フィールドの前に private を付けると、そのクラスの外からは触れなくなります。
Java
class Player {
private int hp = 100;
}
Player p = new Player();
p.hp = -50; // hp has private access in Playerさっきまで通っていた行が、動かす前に、コンパイルの時点で止まります。「実行したら体力がマイナスになっていた」ではなく「そもそも書けない」に変わりました。
private は隠すための仕掛けというより、書き換えていい場所をクラスの中だけに閉じ込める 宣言だと考えてください。容疑者が 20 か所から 1 か所に減ります。
代わりに窓口を開ける
とはいえ、体力が一生変わらないゲームでは困ります。外から呼べるメソッドを用意して、そこだけを通ってもらいます。
Java
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 か所書き忘れた瞬間に残高が壊れます。判定をどこに置くかは、好みではなく壊れやすさの問題です。
要件
- クラス名は
Solution、メソッド名はsafeAccountにすること - 引数は
int initialとint depositの 2 つ、戻り値の型はintにすること depositが0以上のときはinitial + depositを返し、depositが負のときはinitialをそのまま返すこと
入出力例
safeAccount(1000, 500) → 1500
safeAccount(1000, -200) → 1000
safeAccount(0, 100) → 100
safeAccount(500, 0) → 500
safeAccount(0, -50) → 0
safeAccount(123, 877) → 1000ヒント
