レガシー第4章：継承とポリモーフィズム（敵のバリエーションと多態性）

### ■ なぜ仮想デストラクタ（virtual ~Enemy）が絶対に必須なのか？

C++でクラスの継承を扱う際、最も重篤なメモリリークを引き起こす初心者の罠が「**仮想デストラクタの付け忘れ**」です。

#### 1. 悲劇のコード（基底のデストラクタが非仮想の場合）
```cpp
class Enemy {
public:
~Enemy() { /* virtual が付いていない！ */ }
};

class ShieldEnemy : public Enemy {
private:
int* m_shieldData; // 動的確保したリソース
public:
ShieldEnemy() { m_shieldData = new int[100]; }
~ShieldEnemy() { delete[] m_shieldData; } // 解放処理
};

// メイン処理
Enemy* e = new ShieldEnemy();
delete e; // 💥 大惨事発生！
```

#### 2. なぜ大惨事になるのか？
`delete e;` を実行した際、コンパイラはポインタの静的な型（`Enemy*`）しか見ていません。
デストラクタに `virtual` が付いていないと、コンパイラは「Enemyのデストラクタ」だけを静的に呼び出し、**`ShieldEnemy` のデストラクタを完全に無視してメモリを解放します**。
その結果、`ShieldEnemy` 内部で確保した `m_shieldData` のメモリは永遠に解放されず、プログラムは確実にメモリリークで死にます！

#### 3. 解決策：基底クラスには必ず virtual を付ける！
```cpp
class Enemy {
public:
virtual ~Enemy() {} // これ1行で完全解決！
};
```
デストラクタを `virtual` にすると、vtable経由で **派生クラスのデストラクタ（`~ShieldEnemy`）が最初に呼ばれ、その後に基底クラスのデストラクタ（`~Enemy`）が安全に逆順で呼ばれる** ようになります。

#pragma once

// 【第4章：抽象基底クラス Enemy】
// ポリモーフィズム（多態性）の根幹となるインターフェース定義
class Enemy {
protected:
    int m_x;
    int m_y;
    int m_hp;
    bool m_alive;

public:
    Enemy(int x, int y, int hp = 1)
        : m_x(x), m_y(y), m_hp(hp), m_alive(true) {}

    // 【重要：仮想デストラクタ】
    // 基底クラスポインタで破棄された際、派生クラスのデストラクタが必ず呼ばれるようにする
    virtual ~Enemy() {}

    // 【純粋仮想関数（= 0）】
    // 派生クラスに実装を強制する契約
    virtual void update(int dirX, bool moveDown) = 0;
    virtual char getGlyph() const = 0;
    virtual int getScore() const = 0;

    // 共通インターフェース
    virtual bool hit() {
        if (!m_alive) return false;
        m_hp--;
        if (m_hp <= 0) {
            m_alive = false;
        }
        return true;
    }

    bool isAlive() const { return m_alive; }
    int getX() const { return m_x; }
    int getY() const { return m_y; }
    int getHp() const { return m_hp; }
};

#pragma once
#include "Enemy.h"

// 通常インベーダー：標準的な左右往復移動
class NormalEnemy : public Enemy {
public:
    NormalEnemy(int x, int y) : Enemy(x, y, 1) {}

    void update(int dirX, bool moveDown) {
        if (!m_alive) return;
        if (moveDown) {
            m_y += 1;
        } else {
            m_x += dirX;
        }
    }

    char getGlyph() const {
        return 'V';
    }

    int getScore() const {
        return 100;
    }
};

#pragma once
#include "Enemy.h"

// シールド敵：装甲耐久2。1発当たると外装が壊れて 's' になり、2発目で撃破！
class ShieldEnemy : public Enemy {
public:
    ShieldEnemy(int x, int y) : Enemy(x, y, 2) {}

    void update(int dirX, bool moveDown) {
        if (!m_alive) return;
        if (moveDown) {
            m_y += 1;
        } else {
            m_x += dirX;
        }
    }

    char getGlyph() const {
        // 耐久値に応じて見た目が変化（カプセル化された独自表現）
        return (m_hp > 1) ? 'S' : 's';
    }

    int getScore() const {
        return 200;
    }
};

#pragma once
#include "Enemy.h"
#include "Common.h"

// ボーナスUFO：最上段を高速直進し、画面端で自滅する特別敵
class UfoEnemy : public Enemy {
private:
    int m_speed;

public:
    UfoEnemy(int x, int y)
        : Enemy(x, y, 1), m_speed(1) {}

    // 通常の編隊移動（dirXやmoveDown）を無視し、独自の飛行アルゴリズムを実行！
    void update(int /*dirX*/, bool /*moveDown*/) {
        if (!m_alive) return;
        m_x += m_speed;
        if (m_x >= SCREEN_WIDTH - 2) {
            m_alive = false; // 画面外離脱
        }
    }

    char getGlyph() const {
        return 'U';
    }

    int getScore() const {
        return 500;
    }
};

#pragma once
#include <vector>
#include "Player.h"
#include "Enemy.h"
#include "Bullet.h"
#include "Particle.h"

class Game {
private:
    Player m_player;
    // 【重要：基底クラスのポインタを管理するコンテナ】
    // NormalEnemy, ShieldEnemy, UfoEnemy すべてを多態的に一括保持！
    std::vector<Enemy*> m_enemies;
    std::vector<Bullet> m_bullets;
    std::vector<Particle> m_particles;

    int m_score;
    bool m_gameOver;
    bool m_gameClear;
    int m_enemyDir;
    int m_enemyMoveTimer;
    int m_ufoTimer;

    void processInput();
    void update();
    void render();
    void spawnExplosion(int x, int y, bool isUfo = false);

public:
    Game();
    ~Game(); // 動的確保した敵オブジェクトを一括解放
    void run();
};

#include "Game.h"
#include "NormalEnemy.h"
#include "ShieldEnemy.h"
#include "UfoEnemy.h"
#include "Common.h"
#include <iostream>

Game::Game() : m_player(SCREEN_WIDTH / 2 - 1, SCREEN_HEIGHT - 2), m_score(0) {
    // 異なる種類の敵を同じベクターに追加！
    for (int col = 0; col < 6; col++) {
        int x = 4 + col * 4;
        if (col == 2 || col == 3) {
            m_enemies.push_back(new ShieldEnemy(x, 2));
        } else {
            m_enemies.push_back(new NormalEnemy(x, 2));
        }
    }
}

Game::~Game() {
    // 【重要：仮想デストラクタによる安全な解放】
    // Enemy* 経由で delete しても、仮想デストラクタにより各派生クラスが正しく破棄される
    for (size_t i = 0; i < m_enemies.size(); ++i) {
        delete m_enemies[i];
    }
}

void Game::update() {
    // 【多態的ディスパッチ】
    // 敵の種類を意識せず、基底ポインタ経由で update() を呼ぶだけで
    // 各敵固有の実装が自動実行される！
    for (size_t i = 0; i < m_enemies.size(); ++i) {
        if (m_enemies[i]->isAlive()) {
            m_enemies[i]->update(m_enemyDir, hitWall);
        }
    }
}

• 【レガシーOOPの正解】開放閉鎖原則（OCP）と抽象基底クラス: 既存のGameクラスのループコードに一切手を触れずに、新しい敵クラスを追加するだけで機能拡張できる古典的オブジェクト指向の真骨頂。
• 仮想デストラクタの絶対原則: 基底クラスポインタ経由で派生オブジェクトを安全にdeleteするために、基底クラスのデストラクタは必ず virtual にする。
• 動的ディスパッチ（vtable / vptr）のコスト意識: インスタンス毎に4〜8バイトの__vptrを消費し間接呼び出しコストが生じるため、極限の省リソースでは「局所化されたswitch」や「関数ポインタテーブル」と適材適所で使い分ける。

• 1. コンパイルエラーになり、プログラムをビルドできない。
• 2. ShieldEnemy のデストラクタが呼ばれず、Enemy のデストラクタしか実行されないため、メモリリーク等を引き起こす。
• 3. C++が自動的に検知して、常に派生クラスのデストラクタを安全に呼び出してくれる。
• 4. プログラム実行時にセグメンテーション違反で即座にクラッシュする。

正解と解説を見る

正解：ShieldEnemy のデストラクタが呼ばれず、Enemy のデストラクタしか実行されないため、メモリリーク等を引き起こす。
基底クラスのデストラクタが非仮想の場合、静的な型（Enemy*）に基づいて基底クラスのデストラクタしか呼ばれません。派生クラスで確保したリソースの解放処理がスキップされて深刻なメモリリークになるため、基底クラスのデストラクタには必ず virtual を付けるのが絶対鉄則です。

• 1. そのクラスは抽象クラスとなり、単体でインスタンス化（new や変数宣言）することができなくなる。
• 2. すべてのメンバ変数が private から protected に自動変更される。
• 3. 派生クラスでその関数をオーバーライドしてはならない。
• 4. 実行速度が通常の関数より100倍以上遅くなる。

正解と解説を見る

正解：そのクラスは抽象クラスとなり、単体でインスタンス化（new や変数宣言）することができなくなる。
「virtual void update() = 0;」のように末尾に「= 0」を付けた純粋仮想関数を持つクラスは「抽象クラス（Abstract Class）」と呼ばれ、直接インスタンスを生成できなくなります。派生クラスに対して「必ずこの関数を実装せよ」という厳格な契約を強制する役割を果たします。

• 1. mallocテーブル と freeスタック
• 2. 仮想関数テーブル（vtable）と 各インスタンスが持つテーブルポインタ（__vptr）
• 3. RTTI（実行時型情報）による文字列一致検索
• 4. switch-case 文による自動コード生成

正解と解説を見る

正解：仮想関数テーブル（vtable）と 各インスタンスが持つテーブルポインタ（__vptr）
仮想関数を持つクラスをコンパイルすると、クラスごとに仮想関数のアドレスを並べた「vtable（仮想関数テーブル）」が静的に生成されます。また、各インスタンスには先頭に隠しポインタ「__vptr」が埋め込まれ、実行時には __vptr を辿って vtable から該当関数を高速に呼び出します。

• 1. ファイルは常に open() で開き、終了時に必ず close() で閉じなければならないという原則。
• 2. すべてのメンバ変数は private（閉鎖）にし、メンバ関数は public（開放）にしなければならないという原則。
• 3. ソフトウェアの構成要素は、機能拡張に対して開かれており（Open）、既存コードの修正に対して閉じている（Closed）べきであるという原則。
• 4. ソースコードはオープンソースとして公開しなければならないという原則。

正解と解説を見る

正解：ソフトウェアの構成要素は、機能拡張に対して開かれており（Open）、既存コードの修正に対して閉じている（Closed）べきであるという原則。
開放閉鎖原則（OCP）とは、「新機能を追加するとき、既存のテスト済みコードを書き換えることなく、新しいクラスを追加するだけで拡張できるように設計すべきである」という原則です。本章の Enemy 継承設計は、Game クラスのループに手を触れずに新敵を追加できるため、OCP の典型例です。