複数のswitch文を集約し修正漏れを防ぐ！interfaceとストラテジパターンでコードを最適化

コードの保守性を向上させ、バグの発生リスクを抑えるには、冗長なswitch文の管理方法が重要です。特に複数のswitch文が散在するコードでは、修正漏れやメンテナンスの難易度が高くなります。

本記事では、RPGゲームのキャラクター攻撃処理を例に、switch文を集約し、インターフェースとストラテジパターンを活用して保守性と拡張性を向上させる方法を解説します。

この方法は他のプログラミング言語にも応用でき、汎用性が高いアプローチです。

複数のswitch文の問題点

複数のswitch文がコード内に点在していると、保守性や拡張性に悪影響を与えます。以下のような問題点が特に顕著です。

修正漏れのリスク
各switch文が異なる箇所に存在すると、追加や修正が必要な際にすべてのswitch文に同様の変更を加えなければなりません。この手作業による対応は、修正漏れが発生しやすく、バグの原因になりかねません。
コードの冗長化
同じ条件分岐が複数の場所で繰り返されると、コードが冗長になり、可読性が低下します。開発者が意図を理解するのに時間がかかるだけでなく、メンテナンス時に変更箇所を特定しにくくなります。
保守性と拡張性の低下
複数のswitch文を修正する際、各場所を追跡しながら変更する必要があるため、保守が難しくなります。また、switch文を追加するたびにコード全体に影響が及ぶため、コードの拡張性も低くなります。例えば、RPGゲームのキャラクターに新たな攻撃タイプを追加する場合、各switch文に対応する処理を追加しなければならず、非効率的です。
処理の分散による一貫性の欠如
同じロジックを複数のswitch文で実装すると、処理が分散され、コードの一貫性が損なわれます。結果として、処理の流れが見えにくくなり、バグの発見やデバッグが困難になります。

これらの問題は、インターフェースやデザインパターンを利用することで改善できます。特に、switch文を集約し、柔軟性の高い設計を取り入れると、保守性や拡張性が向上し、将来的な変更に強いコードになります。

悪い例のサンプルプログラム

以下は、RPGゲームにおけるキャラクターの攻撃処理を複数のswitch文で定義した悪い例です。キャラクターの攻撃タイプに応じてswitch文が分散しており、攻撃タイプを追加するたびにすべてのswitch文を更新しなければなりません。

public class Character
{
    public string Name { get; set; }
    public string AttackType { get; set; }

    public void PerformAttack()
    {
        switch (AttackType)
        {
            case "Sword":
                Console.WriteLine($"{Name} slashes with a sword!");
                break;
            case "Magic":
                Console.WriteLine($"{Name} casts a spell!");
                break;
            case "Bow":
                Console.WriteLine($"{Name} shoots an arrow!");
                break;
            default:
                Console.WriteLine($"{Name} does nothing.");
                break;
        }
    }
}

public class RPGGame
{
    public void ExecuteAttackAnimation(Character character)
    {
        switch (character.AttackType)
        {
            case "Sword":
                Console.WriteLine("Playing sword attack animation.");
                break;
            case "Magic":
                Console.WriteLine("Playing magic spell animation.");
                break;
            case "Bow":
                Console.WriteLine("Playing bow shot animation.");
                break;
            default:
                Console.WriteLine("Playing idle animation.");
                break;
        }
    }
}

悪い点

複数の場所にswitch文が存在し、新しい攻撃タイプを追加するたびにそれぞれを修正する必要があります。
PerformAttackとExecuteAttackAnimationの2か所で同じ条件分岐が重複しており、保守性が低下しています。

良い例のサンプルプログラム

次は、インターフェースとストラテジパターンを利用してswitch文を1か所に集約した良い例です。攻撃タイプごとに専用のクラスを作成し、それぞれのクラスで異なる攻撃処理とアニメーションを実装することで、修正が簡単になります。

public interface IAttackStrategy
{
    void Attack(Character character);
    void PlayAttackAnimation();
}

public class SwordAttack : IAttackStrategy
{
    public void Attack(Character character)
    {
        Console.WriteLine($"{character.Name} slashes with a sword!");
    }

    public void PlayAttackAnimation()
    {
        Console.WriteLine("Playing sword attack animation.");
    }
}

public class MagicAttack : IAttackStrategy
{
    public void Attack(Character character)
    {
        Console.WriteLine($"{character.Name} casts a spell!");
    }

    public void PlayAttackAnimation()
    {
        Console.WriteLine("Playing magic spell animation.");
    }
}

public class BowAttack : IAttackStrategy
{
    public void Attack(Character character)
    {
        Console.WriteLine($"{character.Name} shoots an arrow!");
    }

    public void PlayAttackAnimation()
    {
        Console.WriteLine("Playing bow shot animation.");
    }
}

public class Character
{
    public string Name { get; set; }
    public IAttackStrategy AttackStrategy { get; set; }

    public void PerformAttack()
    {
        AttackStrategy.Attack(this);
        AttackStrategy.PlayAttackAnimation();
    }
}

良い点

IAttackStrategyインターフェースにより、各攻撃タイプがそれぞれのクラスに実装され、switch文が不要になりました。
攻撃タイプを追加する際は、IAttackStrategyを実装した新しいクラスを追加するだけで済み、他のコードに変更を加える必要がありません。
各クラスがそれぞれの攻撃処理を持つため、コードの可読性と拡張性が向上します。

インターフェースとストラテジパターンの効果

インターフェースとストラテジパターンを導入することで、コードの保守性や拡張性が大幅に向上します。以下は、具体的な効果です。

修正漏れの防止
複数のswitch文を1つの戦略に統合することで、修正箇所を1か所に集約できます。新しい攻撃タイプを追加しても、新たなクラスを作成するだけで対応可能なため、修正漏れのリスクを減らせます。
コードの再利用性向上
インターフェースを利用することで、共通の操作を統一的に扱えるため、コードの再利用性が高まります。また、異なる機能を追加する際も、インターフェースを実装した新しいクラスを追加するだけで柔軟に対応できます。
拡張性の向上
ストラテジパターンは「オープン・クローズド原則」（新しい要件には開かれているが、既存コードの変更には閉じている）に基づいており、新しい攻撃タイプを追加する際、既存コードを変更せずに拡張が可能です。将来的な機能拡張に強く、コードの安定性を保てます。
コードの可読性向上
各攻撃タイプごとに専用のクラスが用意されるため、コードがわかりやすくなり、可読性が向上します。特に、大規模プロジェクトで複数の開発者が関わる場合、この構造により誰が見ても理解しやすいコードとなります。