【1日45分×6日でわかる】オブジェクト指向 Day3: カプセル化とアクセス修飾子

これまで作ったクラスは、`dog.name = “”` のように外から自由にフィールドを書き換えられました。しかし現実のデータには「マイナスの残高は許さない」といったルールが必要です。今日は、データを守る仕組み「カプセル化」と「アクセス修飾子」を学びます。45分で、安全な銀行口座クラスを作ります。時間配分の目安は、説明10分、実践27分、振り返り8分です。

カプセル化とアクセス修飾子(目安10分・インプット)

カプセル化とは、データを外から直接触れないように隠し、決められた方法(メソッド)を通してのみ扱えるようにする考え方です。これを実現するのがアクセス修飾子です。主なものは、どこからでもアクセスできる `public` と、同じクラス内からしか触れない `private` です。

フィールドを `private` にして隠し、値を取り出す・変更する処理は `public` のメソッドとして用意するのが基本形です。

public class BankAccount {
    private int balance;   // 外から直接触れない

    public void deposit(int amount) {
        if (amount > 0) {          // 不正な入金を防ぐ
            balance += amount;
        }
    }

    public int getBalance() {      // 残高を取り出す
        return balance;
    }
}

【実践】安全な口座クラスを作る(目安27分・手を動かす)

上の `BankAccount.java` と、次の `Main.java` を実行しましょう。

public class Main {
    public static void main(String[] args) {
        BankAccount acc = new BankAccount();
        acc.deposit(1000);
        acc.deposit(-500);   // 不正なので無視される
        System.out.println("残高: " + acc.getBalance());
    }
}

`java Main` の結果は「残高: 1000」になります。マイナスの入金がメソッド内のチェックで弾かれるのがカプセル化の効果です。試しに `Main` の中で `acc.balance = 9999;` と直接書いてみてください。privateのためコンパイルエラーになり、勝手な書き換えが防がれていることが確認できます。演習として、残高を超える出金を拒否する `withdraw` メソッドを追加してみましょう。

よくある疑問・つまずきポイント

**なぜわざわざprivateにするのですか?**

外から自由に書き換えられると、ルール(マイナス残高禁止など)を守れません。窓口(メソッド)を1か所に絞ることで、安全で壊れにくいクラスになります。

**protectedという修飾子も見かけます。**

`protected` は、同じパッケージと、継承した子クラスからアクセスできる中間的な修飾子です。継承を学ぶ明日以降に関わってきます。

まとめ(目安8分)

今日はカプセル化で、privateとpublicを使い分けてデータを守る方法を学びました。安全なクラス設計の第一歩です。明日は、既存のクラスをもとに新しいクラスを作る「継承」に進みます。

コメント

タイトルとURLをコピーしました