コード読解演習 Step 10【構造鑑識】：アーキテクチャレビューと密結合コードの依存構造分析

### 健全なDAG vs 破綻した循環結合

ソフトウェアの依存関係は、数学的に以下の2つのどちらかになります：

- ⭕ **DAG（Directed Acyclic Graph：有向非巡回グラフ）**:
- 依存の矢印を辿っていっても、決して元のクラスに戻らない構造。
- 利点: 変更の影響範囲が下流にしか及ばず、並行コンパイルが爆速で走り、末端の部品から単体テストできる。
- ❌ **循環結合（Circular Cycles）**:
- A ➔ B ➔ C ➔ A と矢印が一周している構造。
- 弊害: どこか1箇所を変更すると全員に波及し、単体テストしようとしても全システムをリンクしなければ動かない。

この蟻地獄を断ち切る武器が、**「前方宣言による物理依存の切断」** と **「DIP（依存性逆転の原則）による論理依存の逆転」** です。

• 依存関係にループ（循環）を絶対に許すな: 矢印が一周した時点で、そのクラス群は独立した部品ではなく「分割されたフリをした1つの巨大な神クラス」に成り下がります。

### 前方宣言ができる条件・できない条件

コンパイラがクラスの「完全な定義（#include）」を必要とするのは、**「そのオブジェクトのメモリサイズ（sizeof）やメンバ変数の中身を知らなければならない時」** だけです：

| ケース | 前方宣言でOK？ | 理由 |
| :--- | :--- | :--- |
| 「class Player;」でポインタ保持 (Player* p;) | ⭕ **OK（推奨）** | ポインタのサイズは常に8バイト（64bit）で固定だから |
| 関数の引数・戻り値で参照渡し (void hit(Player& p);) | ⭕ **OK（推奨）** | アドレスを渡すだけなので中身を知る必要がない |
| 実体メンバとして保持 (Player m_player;) | ❌ **NG (#include必須)** | Player全体のバイト数を知らないとメモリ確保できない |
| メンバ関数を呼び出す (p->attack();) | ❌ **NG (#include必須)** | 関数オフセットやシグネチャが必要（.cpp側でincludeする） |

#### 【実践ルール】
**「ヘッダ（.h）には前方宣言だけを書き、実体やメンバ関数呼び出しが必要な実装ファイル（.cpp）の中だけで #include を書く」**。
これだけで、ヘッダの変更による再コンパイルの波及を90%以上遮断できます。

// ❌ 【悪いヘッダ】無関係な巨大ヘッダをインクルードしまくる
// #include "HeavyMonster.hpp"
// #include "SoundEngine.hpp"
// #include "UiRenderer.hpp"

// ⭕ 【美しいヘッダ】ポインタと参照のみなので前方宣言で物理依存を完全切断！
class HeavyMonster;
class SoundEngine;
class UiRenderer;

class BattleArena {
private:
    HeavyMonster* m_boss;   // サイズは8バイト固定。Monsterの中身を知る必要ゼロ！
    SoundEngine*  m_sound;

public:
    BattleArena();
    ~BattleArena();

    // 参照渡しなので前方宣言だけでシグネチャ成立！
    void registerBoss(HeavyMonster& boss);
    void render(UiRenderer& ui);
};

// 実際の Monster->takeDamage() 等の呼び出しは
// BattleArena.cpp の中で #include "HeavyMonster.hpp" して行う！

• ヘッダに #include を書く前に「ポインタで済まないか」問え: 前方宣言の活用により、ヘッダ同士の結合度（ファンイン/ファンアウト）を最小化し、ビルド時間と循環依存を一挙に撲滅できます。

### 依存性逆転の原則（Dependency Inversion Principle: DIP）

オブジェクト指向設計の最高峰原則である **DIP** はこう述べています：

1. **上位モジュール（GamePlay）は下位モジュール（Sound/Network/Render）に直接依存してはならない。両者は「抽象（Interface）」に依存すべきである。**
2. **抽象は詳細に依存してはならない。詳細が抽象に依存すべきである。**

もし「Player」クラスが「DirectXSoundSystem」クラスを直接 new して呼んでいたら、サウンドシステムの変更で Player が壊れ、音の出ない単体テスト環境では Player クラスをリンクすることすらできなくなります。

#### 【外科手術の手順】
1. 純粋仮想インターフェース「ISoundService」（virtual void playSound(int id) = 0;）を新設する。
2. Player は「ISoundService&」だけを受け取って呼び出す（Player の依存の矢印がインターフェースへ向かう）。
3. 本番用「DirectXSoundSystem」とテスト用「MockSoundSystem」を「ISoundService」から派生させる。
4. **依存の向きが逆転！** Player はサウンド実装の詳細を一切知らず、単体テストでもモックを渡して1ミリ秒で検証可能になる！

// ⭕ 【抽象インターフェース】依存のクッション
class IAudioPlayer {
public:
    virtual ~IAudioPlayer() {}
    virtual void playSfx(int soundId) = 0;
};

// ⭕ 【高水準ビジネスロジック】具体的な音響APIを知らない！
class SpaceShip {
private:
    IAudioPlayer& m_audio; // 抽象にのみ依存
    int m_hp;

public:
    SpaceShip(IAudioPlayer& audio) : m_audio(audio), m_hp(100) {}

    void onTakeDamage(int dmg) {
        m_hp -= dmg;
        m_audio.playSfx(42); // 爆発音をリクエスト（誰がどう鳴らすかは知らん！）
    }
    int getHp() const { return m_hp; }
};

// -------------------------------------------------------------
// 🧪 【単体テスト】サウンドカードのないCIサーバーでも爆速検証！
class MockAudioPlayer : public IAudioPlayer {
public:
    int lastPlayedId = -1;
    void playSfx(int soundId) override { lastPlayedId = soundId; }
};

void testSpaceShipDamage() {
    MockAudioPlayer mockAudio;
    SpaceShip ship(mockAudio);

    ship.onTakeDamage(30);

    assert(ship.getHp() == 70);
    assert(mockAudio.lastPlayedId == 42 && "ダメージ時に爆発音が鳴っていません！");
    printf("単体テスト完全パス！ハードウェア依存ゼロ！\n");
}

• インターフェースを境界に差し挟み、依存を逆流させよ: 具象クラス同士の直接結合を断ち切り、純粋仮想クラスを挟むことで、部品の交換可能性とテスト容易性が極限まで高まります。

• 1. #include "Enemy.hpp" を必ず書く
• 2. class Enemy; と前方宣言（Forward Declaration）を行い、ヘッダレベルでのインクルード依存を切断する
• 3. Enemy クラスの定義をヘッダ内に直接コピー＆ペーストする
• 4. void* にキャストして型情報を消す

正解と解説を見る

正解：class Enemy; と前方宣言（Forward Declaration）を行い、ヘッダレベルでのインクルード依存を切断する
ポインタや参照はアドレス（固定サイズ）を保持するだけなので完全な定義を必要とせず、前方宣言で済ませることで再コンパイルの波及を劇的に抑えられます。

• 1. 画面の色が反転する
• 2. 2つのクラスが不可分に密結合し、単体テストや部品単体での再利用が不可能になり、全再コンパイルが誘発される
• 3. 関数の実行速度が半分になる
• 4. C++コンパイラがC言語モードに切り替わる

正解と解説を見る

正解：2つのクラスが不可分に密結合し、単体テストや部品単体での再利用が不可能になり、全再コンパイルが誘発される
循環依存が発生すると、部品ごとの独立性が失われ、単体テスト・モジュール分割・並行ビルドがすべて阻害されます。

• 1. グローバル変数
• 2. 純粋仮想関数を持つ抽象インターフェース（例: ISoundService）
• 3. goto文によるジャンプテーブル
• 4. OSのシステムコール

正解と解説を見る

正解：純粋仮想関数を持つ抽象インターフェース（例: ISoundService）
抽象インターフェースを間に挟むことで、上位モジュールも下位モジュールも抽象に依存する形となり、モックへの差し替えや単体テストが極めて容易になります。

• 1. クラスの private メンバ変数の変更が公開ヘッダに一切波及せず、他ファイルの再コンパイルを完全に防げる
• 2. メモリ使用量が必ず1バイトになる
• 3. 仮想関数の呼び出しコストがゼロになる
• 4. C++のコードがPythonに自動変換される

正解と解説を見る

正解：クラスの private メンバ変数の変更が公開ヘッダに一切波及せず、他ファイルの再コンパイルを完全に防げる
Pimplイディオムは内部実装を不透明ポインタの先の構造体に隠蔽するため、プライベート変数を変更しても公開ヘッダが一切変わらず、巨大プロジェクトの再ビルドを劇的に削減します。