継承（インヘリタンス）
親から受け継いだ秘伝のレシピ帳に、自分だけの特製ソースの作り方を書き足して、新しい看板メニューを完成させるようなものです。
定義 親から譲り受けた丈夫な自転車に、前かごやライトを新たに取り付けて自分好みの自転車に仕上げるように、プログラミングでもすでに完成している設計図を受け継ぎ、新しい機能を追加する仕組みがあります。これを「継承（インヘリタンス／Inheritance）」と呼びます。 既存のクラス（プログラムの設計図）が持つ属性や機能をそのまま引き継ぎ、重複したコードを書くことなく、必要な部分だけを追加・修正して新しい設計図を手軽に作ることができます。
土台をそのまま受け継いで新しいものを作る
スマホゲームでたくさんのモンスターを作る場面をイメージしてみましょう。スライム、ドラゴン、ゾンビなど、どのモンスターも基本的に「体力」や「移動速度」を持ち、「移動する」「攻撃を受ける」といった共通の動きをします。
新しいモンスターを作るたびに、同じ基本コードを最初から書き直していては、時間がかかるだけでなくタイプミスなどのミスも起きやすくなります。そこで、共通する機能だけをまとめた「基本モンスター」の設計図をあらかじめ1つ作っておけば、この問題はすっきり解決します。
ドラゴンの設計図を作るときに基本モンスターの設計図を継承すれば、基礎的な機能はすでに揃った状態からスタートできます。開発者はそこに「炎を吐く」「空を飛ぶ」といったドラゴンならではの個性的な機能だけを追加すればよいのです。このように既存の設計をそのまま受け継いで無駄をなくすことが、コードの再利用を最大限に高める継承の最大のメリットです。
受け継いだ機能を自分流にカスタマイズする
親から譲り受けた服を自分のサイズに合わせて仕立て直すように、継承した機能も子となる設計図側で新しく書き換えることができます。プログラミングではこれを「メソッドのオーバーライド（機能の再定義）」と呼びます。
たとえば、基本モンスターの「移動する」機能がトコトコ歩く動作だったとしましょう。しかし、巨大な翼を持つドラゴンが地面をとぼとぼ歩いていたら少し不自然ですよね。
そんなときは、継承した「移動する」という命令の名前はそのままで、実際の中身だけを空を飛ぶ動きへと上書きすることができます。指示を出す側はどのモンスターに対しても「移動しろ！」と命じるだけで済み、各モンスターは自分専用に再定義された動きで個性豊かに動くようになります。
もう少し詳しく：何でもかんでも継承すればいいわけではない
もう少し詳しく言うと、継承がいつでも万能というわけではありません。継承関係を深く複雑にしすぎると、親の設計図をほんの少し変更しただけで、何十個もの子設計図が次々と壊れてしまう致命的な問題が起こり得ます。
プログラミングでは、親と子が強く結びつきすぎて切り離せない状態を「結合度が高い」と表現します。親の設計図が変わると子の設計図にまで予測不能な影響が及ぶため、後からコードを修正するのが非常に難しくなってしまうのです。
そのため、現代のソフトウェア設計では、安易に継承を使うよりも、必要な機能パーツをレゴブロックのように組み合わせて使う委譲・コンポジション（合成）という手法が推奨されることも多くなっています。継承は「AはBの明確な一種である（is-a関係）」という関係が成り立っている場合にのみ、慎重に使うことでプログラムを頑丈に保てます。
🤔 よくある誤解
継承をたくさん使えば使うほど、コードはすっきりして優れたプログラムになる。
継承を過度に多用すると、親クラスと子クラスの結びつきが強くなりすぎてしまいます。後から親のコードを少し直しただけで、子プログラムが連鎖的に動かなくなる危険性があります。
🧺 日常で出会う場面
継承とは、既存の設計図（クラス）が持つ機能や属性を受け継ぎ、コードの重複をなくして効率的かつ安全に新しいプログラムを作るオブジェクト指向の基本技術です。