3分間プログラミング講座 第4回: クラスの「秘密」と「窓口」～カプセル化～
登場人物：
チャット先生（通称:先生）： オブジェクト指向マスター。普段は優しく、たまにユーモアも交えながら解説。
ボット助手（通称:ボット君）： プログラミングを始めたばかりの若手。素朴な疑問を投げかけるのが得意。
ボット君： 先生、今日は「カプセル化」について教えてくれるんですよね！「内部の秘密は隠して、必要な部分だけを外に見せる」って、なんだかスパイ映画みたいでワクワクします！
先生： ハハハ、ボット君らしい表現だね！まさにその「隠す」という考え方が、今日のテーマ「カプセル化」の核心だよ。オブジェクト指向の三大要素（カプセル化、継承、ポリモーフィズム）の一つで、とても大切な概念なんだ。
ボット君： 三大要素！そんなに重要なんですね！
先生： そうだよ。前回は「単一責任の原則」で、クラスの役割を明確に分けることの重要性を学んだね。カプセル化は、そうやって分けたクラスが、お互いに安全に、そして効率的にやり取りするための仕組みなんだ。
カプセル化とは？～「隠蔽」と「公開」～
先生： まず、カプセル化を理解するために、身近な例を考えてみよう。ボット君、テレビのリモコンを想像してみて。
ボット君： はい、あります！チャンネル変えたり、音量変えたりできますよね。
先生： その通り。リモコンのボタンを押すと、テレビがちゃんと動くよね。でも、リモコンの「中身」がどうなっているか、知っているかい？中にどんな回路があって、どんな電気信号が送られているか。
ボット君： うーん、全然知らないです。ボタンを押せば動くから、別に知らなくても困らないです！
先生： まさにそれがカプセル化の考え方なんだ！
先生： リモコンは、
複雑な内部の仕組み（回路や電気信号）を「隠して」いる。
必要な操作だけを「ボタン」という形で外に「公開」している。
ボット君： ああ！だから、誰でも簡単にテレビを操作できるんですね！中身を知らなくても使える！
先生： その通り！プログラミングのクラスも同じで、
**オブジェクトの持つデータ（属性）や、そのデータを操作する細かい手順（メソッドの内部実装）**といった「秘密」を、外部から直接触れないように「隠蔽（隠す）」する。
そして、外部に公開しても安全で、必要だと判断された操作だけを「窓口（メソッド）」として提供する。
これを「カプセル化」と呼ぶんだ。
なぜ「隠蔽」するのか？～勝手に触られたら困る！～
先生： なぜわざわざ隠す必要があると思う？誰でも自由に触れた方が、便利じゃないかな？
ボット君： うーん……でも、リモコンの中身を勝手にいじったら、壊しちゃいそうです。テレビが変な動きをしたり……。
先生： その通り！プログラムでも同じことが起こるんだ。例えば、前回のCarクラスで考えてみよう。
Java
public class Car {
String color; // 色
int speed; // 速度
// ... 他の属性とメソッド ...
}
先生： もしspeedという属性を誰でも直接変更できるようにしていたら、どうなると思う？
Java
Car myCar = new Car("赤", "トヨタ");
myCar.speed = 1000; // 突然、とんでもない速度に！
ボット君： うわあ！いきなり時速1000kmに！？それだと、accelerate()メソッドでちゃんと段階的に加速する意味がなくなっちゃいますね！危ない！
先生： その通り。勝手にデータを書き換えられたり、想定外の操作をされると、プログラムの整合性が壊れてしまう。まるで、テレビのリモコンの電池を入れ替えるつもりが、中の基盤をめちゃくちゃにしてしまうようなものだね。
先生： だから、クラスの内部にあるデータや、外部に見せるべきではない細かい処理は、「private（プライベート）」というアクセス修飾子を使って「秘密」にするんだ。これで、同じクラス内からしかアクセスできないようになる。
「窓口」としてのメソッド～getterとsetter～
先生： じゃあ、隠したデータにアクセスしたり、操作したりしたい場合はどうすればいいと思う？
ボット君： リモコンのボタンみたいに、「窓口」を作るんですよね！
先生： そう！その「窓口」となるのが、外部に公開するメソッドなんだ。特に、データを取得するためのメソッドを「getter（ゲッター）」、データを設定するためのメソッドを「setter（セッター）」と呼ぶことが多いよ。
Java
public class Car {
private String color; // privateにして隠す
private String maker; // privateにして隠す
private int speed; // privateにして隠す
// コンストラクタ：オブジェクトを作る時に必ず実行される特別なメソッド
public Car(String color, String maker) {
this.color = color;
this.maker = maker;
this.speed = 0; // 初期速度は0
System.out.println(this.maker + "製の" + this.color + "の車が作られました！");
}
// color属性のgetter（色を取得する窓口）
public String getColor() {
return this.color;
}
// maker属性のgetter（メーカーを取得する窓口）
public String getMaker() {
return this.maker;
}
// speed属性のgetter（速度を取得する窓口）
public int getSpeed() {
return this.speed;
}
// speed属性のsetter（速度を設定する窓口）
// 速度は不正な値にならないよう、ここでチェックできる！
public void setSpeed(int speed) {
if (speed < 0) {
System.out.println("エラー: 速度は0未満にできません。");
return; // 不正な値の場合は設定しない
}
if (speed > 300) { // 例：最大速度を300km/hに制限
System.out.println("警告: 速度が制限を超えています。300km/hに制限します。");
this.speed = 300;
return;
}
this.speed = speed;
System.out.println("速度を" + speed + "km/hに設定しました。");
}
// accelerateメソッド（加速する窓口）
public void accelerate(int accelerationSpeed) {
// setSpeedメソッドを使って、安全に速度を設定できる
setSpeed(this.speed + accelerationSpeed);
// setSpeed内で出力しているので、ここでは追加の出力は不要
}
public void brake() {
setSpeed(0); // setSpeedメソッドを使って、安全に停止状態にする
System.out.println(this.maker + "の車が停止しました。");
}
}
ボット君： おお！privateって書くと外から直接触れないようになるんですね！でもgetColor()とかsetSpeed()を使えば、安全にデータを見たり変えたりできるんだ！setSpeed()で変な値が入らないようにチェックできるのもすごい！
先生： その通り！これがカプセル化の大きなメリットの一つだ。内部のデータへの不正なアクセスを防ぎ、データの整合性を保つことができるんだ。
先生： ちなみに、colorのsetterは作らなかったことに気づいた？
ボット君： あ、本当ですね！なぜですか？
先生： 車の色は通常、製造後に変更することはないからね。このように「必要な窓口だけを提供する」のも、カプセル化の重要な考え方なんだ。何でもかんでもgetterとsetterを作る必要はないんだよ。
先生： では、実際にカプセル化されたCarクラスの使い方を見てみよう。
Java
public class CarTest {
public static void main(String[] args) {
Car myCar = new Car("赤", "トヨタ"); // コンストラクタが呼ばれる
// これは正しい使い方（公開されたメソッドを使用）
System.out.println("車の色: " + myCar.getColor());
System.out.println("車のメーカー: " + myCar.getMaker());
System.out.println("現在の速度: " + myCar.getSpeed() + "km/h");
myCar.accelerate(50); // 安全に加速 (setSpeed内部で出力)
myCar.setSpeed(30); // 安全に速度を設定（チェックが働く）(setSpeed内部で出力)
System.out.println("新しい速度: " + myCar.getSpeed() + "km/h");
myCar.brake(); // 安全に停止 (setSpeed内部で出力)
// これはコンパイルエラーになる（privateなので外部から直接アクセス不可）
// myCar.speed = 1000; // コンパイルエラー！
// System.out.println(myCar.color); // コンパイルエラー！
}
}
先生： このコードを実行すると、次のような結果になるはずだよ。
/* 実行結果例:
トヨタ製の赤の車が作られました！
車の色: 赤
車のメーカー: トヨタ
現在の速度: 0km/h
速度を50km/hに設定しました。現在の速度は50km/hです。
速度を30km/hに設定しました。現在の速度は30km/hです。
新しい速度: 30km/h
トヨタの車が停止しました。
*/
ボット君： おお！privateにしたものは、直接触ろうとするとエラーになるんですね！
先生： その通り！これにより、コンパイル時点で不正なアクセスを防げるんだ。
カプセル化のメリットと「アクセス修飾子」
先生： このカプセル化によって、どんなメリットが生まれると思う？
ボット君： えーと、勝手にいじられて壊れる心配がなくなる！あと、中身がどうなっているか知らなくても使えるから、便利！
先生： 素晴らしい！まさにその通りだ。
データの保護と整合性の維持: 外部からの不正なアクセスを防ぎ、データが意図しない形で変更されるのを防ぐ。これにより、常に正しい状態を保てる。
変更への強さ: 内部の実装（例えば、速度の計算方法）を変更しても、公開している窓口（メソッドのインターフェース）が変わらなければ、そのクラスを使う側のコード（外部のコード）を修正する必要がない。
使いやすさの向上: 内部の複雑さを隠蔽することで、ユーザー（そのクラスを使う他のプログラマー）は、公開されたシンプルな窓口だけを使えばよく、簡単に利用できる。
保守性の向上: クラスの内部と外部の境界が明確になるため、バグ修正や機能追加の際に影響範囲を限定しやすい。
ボット君： なるほど！カプセル化って、クラスを「ブラックボックス」にして、外から安全に使えるようにする仕組みなんですね！「単一責任」でクラスの役割を明確にして、「カプセル化」でそのクラスの安全性を高める。だんだんつながってきた気がします！
先生： その調子だ、ボット君！オブジェクト指向の概念が、一つ一つ組み合わさって、より堅牢で管理しやすいプログラムを作るための「設計思想」になっているのが見えてきたかな？
先生： ちなみに、カプセル化には「どこまで隠すか」のレベルがあるんだ。このprivateやpublicといったキーワードを「アクセス修飾子」と呼ぶよ。
ボット君： レベルですか？
先生： そう。例えば：
private: 同じクラス内からのみアクセス可能（最も厳格）
public: どこからでもアクセス可能（最も開放的）
他にもprotectedなどがあるけど、それはまた今度説明するね。
基本的には「必要最小限だけを公開する」という考え方が大切なんだ。
今日のまとめ！
カプセル化：
オブジェクトの内部データ（属性）や詳細な実装を外部から「隠蔽（プライベートにする）」すること。
外部に必要な操作だけを「窓口（公開メソッド、特にgetter/setter）」として提供すること。
目的：データの保護と整合性の維持、外部からの不正なアクセス防止。
メリット：
データの保護と整合性の維持：意図しない変更からデータを守る。
変更への強さ：内部実装が変わっても外部コードに影響を与えにくい。
使いやすさの向上：ユーザーは複雑な内部を知らなくても、シンプルな窓口で利用できる。
保守性の向上：修正や追加の影響範囲を限定しやすい。
アクセス修飾子：private（同じクラス内からのみアクセス可能）やpublic（どこからでもアクセス可能）などを使って、公開レベルを制御する。
ボット君： 先生、今日は「カプセル化」について、とてもよく分かりました！クラスの「秘密」と「窓口」の関係、これでバッチリです！これで変な速度に車がなったりしなくなりますね！
先生： その通りだ、ボット君！これで君のプログラムは、より安全で、他の人にも使いやすいものになるだろう。次回は、オブジェクト指向の三大要素の最後、「継承」について学んでいこう。共通の設計図を元に、新しい設計図を作る方法だよ。
ボット君： 継承！なんか親子関係みたいで面白そうです！楽しみです！ありがとうございました！
次回：第5回:「共通の設計図」から「新しい設計図」を作る～継承～
いいなと思ったら応援しよう！
もしこの記事が少しでも役に立ったり、楽しんでいただけたりしたら、チップをいただけるととても嬉しいです！
いただいたチップは、今後のより良いコンテンツ制作のための書籍代📚とnote購入🗒️、他の方へのチップ代💰に使わせていただきます。
いつも応援ありがとうございます！