オーバーロード・オーバーライド・ポリモーフィズムを改めて整理してみた話
最近、クラス設計やポリモーフィズムについて勉強していて、
「正直、こんなに分ける必要ある？」と思うことが増えました。
特にオーバーライドや継承を使うとファイルやクラスが増えて、
**「後で触るプログラムが増えるのが嫌だ」**と感じる瞬間が多い。
でも、それでもやっぱり分ける意味がある――そう思えたので整理しておきます。
🧩 オーバーロードとオーバーライドの違い
| 項目 | オーバーロード | オーバーライド |
|---|---|---|
| 定義場所 | 同じクラス内 | 親クラスを継承した子クラス内 |
| 条件 | メソッド名が同じで引数が異なる | メソッド名・引数が同じで中身を上書き |
| 目的 | 似た処理をまとめて使いやすくする | 親の共通処理を引き継ぎつつ、部分的に変える |
例で言えば、speak()という関数を
- 犬なら「ワン！」
- 猫なら「ニャー」
とそれぞれに上書き（＝オーバーライド）するのが典型ですね。
🧠 ポリモーフィズムとは
ポリモーフィズム（多態性）は、**「同じメソッドを呼んでも実体によって動作が変わる」**こと。
つまり、animal.speak()と書くだけで、
Dogなら「ワン！」、Catなら「ニャー」が出る。
こうすることで、
呼び出す側は“動物”という抽象だけを見ればいい。
新しい動物を追加しても、呼び出し側は一切変更しなくて済む。
ここが最大のメリットです。
🧱 カプセル化と副作用
カプセル化は、内部のデータ構造を外から直接触らせないようにする設計。
これによって「どこを直せば壊れるか」が明確になり、変更が安全になります。
副作用とは、関数外の状態を変えること（例：グローバル変数の変更、I/Oなど）。
構造化プログラミングではこれを慎重に扱い、
関数型プログラミングでは極力排除しようとします。
こうした設計の意図は、すべて「後から触りやすくする」ためです。
💬 「プログラムが増えるのが嫌」という気持ち
正直、設計を丁寧に分けるとファイルやクラスがどんどん増えていきます。
- 「修正箇所が分散してて、どこ直せばいいか分からない」
- 「似たようなファイルが多くて混乱する」
こういう感覚、よく分かります。
ですが、プログラムが“増える”ことと“複雑になる”ことは別です。
クラスを分けて責任を小さくしておくことで、
- 修正の影響範囲が限定される
- テストしやすくなる
- 他人が読んでも理解しやすい
つまり「一時的に増えるけど、長期的には触りやすくなる」というトレードオフです。
🚀 まとめ
- オーバーロード：同名メソッドを使い分ける
- オーバーライド：親クラスの動作を子で上書き
- ポリモーフィズム：呼び出す側が具体的な型を意識しなくて済む
- カプセル化：変更に強く、予期せぬ副作用を防ぐ
プログラムが増えるのは確かに面倒。
でも、それを超えるだけの「安全さと拡張性」を得られるのが、
オブジェクト指向設計の一番の魅力だと思います。
✍️ 一文でまとめると
設計を分けるのは、今を楽にするためじゃなく、未来を壊さないため。