カプセル化

ここから、オブジェクト指向の三大要素を1つずつ攻略します。1つ目はカプセル化です。

Chapter 1で、残高に -999999 を直接代入できてしまう問題を見ました。Chapter 3のTodoListにも実は同じ穴があります。list.titles.push("重複タスク") と書けば、せっかくの重複チェックを素通りできてしまう。メソッドでルールを書いても、データ自体がむき出しなら、ルールは迂回できるのです。

カプセル化とは、この穴を塞ぐ考え方です。やることは2つ:

・ データを外から直接触れなくする(隠す)

・ 代わりに、正規の操作(メソッド)だけを公開する

守りたいのは「ありえない状態を作らせない」こと

銀行口座で考えます。口座には「残高は0未満にならない」という、絶対に守られるべき約束があります。こういう「このクラスのデータが常に満たしているべき条件」を意識するのが、カプセル化の出発点です。

まず、守りが無いとどうなるか。withdraw にチェックを入れた、一見ちゃんとした実装です。最後のconsole.logが何を表示するか予想してから実行してください。

「残高不足です」と断った直後に、-999999。withdraw の中にどれだけ丁寧なチェックを書いても、正面玄関の横に壁の穴が開いている状態です。

---

private: 外から触れなくする

TypeScriptでは、プロパティ宣言に private を付けると、クラスの外からのアクセスが禁止されます。

実行すると1300。そして最後の行のコメントを外すと、この代入は「プロパティ ‘balance’ はプライベートです」という型エラーになり、実際の開発環境ではエディタに赤線が引かれてコンパイルが通りません。壁の穴が塞がりました。

残高を読む手段としては getBalance() メソッドを公開しています。これがカプセル化の公開設計です:

「できないこと」が仕様として明記されているのがポイントです。利用者は壊しようがなく、クラスの作者は「残高が0未満になることはない」と保証できます。この保証こそ、カプセル化が生む価値です。

もうひとつのprivate: