WinFormアプリで シンプルなコードからStateパターンへ移行しよう
このチュートリアルでは、簡単なキャラクターのステータス管理プログラムを作成し、それをより柔軟で拡張しやすい設計に改善する方法を学びます。まず、シンプルなコードを書き、その後、Stateパターンというデザインパターンを導入して、コードの設計を改善していきます。
ステップ1: シンプルなコードを作成する
まずは、以下のシンプルなコードを見てください。このコードは、コンボボックスから選択されたキャラクターの状態（Normal、Attacking、Defending）に応じてメッセージを表示するものです。
public partial class Form1 : Form
{
private string currentState;
public Form1()
{
InitializeComponent();
comboBox1.Items.Add("Normal");
comboBox1.Items.Add("Attacking");
comboBox1.Items.Add("Defending");
currentState = "Normal"; // 初期状態
}
private void button1_Click(object sender, EventArgs e)
{
switch (comboBox1.SelectedItem.ToString())
{
case "Normal":
currentState = "キャラクターは通常状態です。";
break;
case "Attacking":
currentState = "キャラクターは攻撃しています！";
break;
case "Defending":
currentState = "キャラクターは防御しています！";
break;
}
MessageBox.Show(currentState);
}
}このコードは、シンプルで理解しやすいですが、キャラクターの状態が増えるたびにswitch文を追加する必要があり、コードが複雑になりがちです。
ステップ2: 問題点を理解する
この設計には、以下のような問題があります：
- コードの一貫性の欠如: switch文を使用して状態ごとに異なる処理を追加しているため、メソッドが複数の責任を持ち、肥大化しがちです。これにより、コードが一貫性を欠き、他の開発者が理解しにくくなります。
- 保守性の低下: 新しい状態を追加するたびに、Form1クラス内でswitch文に新しいケースを追加しなければなりません。これにより、Form1クラスが状態の実装に依存し、保守が難しくなります。また、コードの変更が複数箇所に広がるため、ミスが発生しやすくなります。
- 拡張性の問題: 他の部分でも同様のロジックが必要になった場合、switch文の重複が発生する可能性が高く、拡張が困難です。
Stateパターンの利点
Stateパターンを導入することで、switch文を保持しながらも以下のような改善が見込めます：
- クラスの責任を分離: 各状態を独立したクラスとして分離することで、Form1クラスが「どの状態にあるか」だけを担当し、「状態がどのように動作するか」は個別のクラスに委譲できます。これにより、クラスの責任が明確になります。
- コードの集中化: 新しい状態を追加する際に、Form1クラスではなく、専用のクラスを作成するだけで済みます。これにより、コードの変更箇所が集中し、保守が容易になります。
- 再利用性の向上: 状態ロジックが個別のクラスに集約されているため、他のコンテキストでも再利用可能です。これにより、同じロジックを繰り返し書く必要がなくなります。
このように、Stateパターンを使うことで、コードの冗長性自体を直接的に減らすわけではありませんが、クラスの責任を明確にし、保守性や拡張性を大幅に向上させることができます。
ステップ3: Stateパターンの基本を学ぶ
Stateパターンとは？
Stateパターンは、オブジェクトの状態をカプセル化し、状態に応じた動作を実装することで、状態の変化による処理の分岐をクラスで表現するデザインパターンです。
Stateパターンの構成
- インターフェース: 共通の動作を定義する
IStateインターフェースを作成します。 - 具体的な状態クラス:
IStateインターフェースを実装する具体的な状態クラス（NormalState、AttackingState、DefendingState）を作成します。 - コンテキストクラス: 現在の状態を保持し、それに応じた動作を実行する
Characterクラスを作成します。
ステップ4: Stateパターンを適用する
それでは、シンプルなコードをStateパターンを使って改善してみましょう。
1. IStateインターフェースを作成する
まず、状態の動作を定義するインターフェースを作成します。
public interface IState
{
string Handle();
}2. 具体的な状態クラスを別ファイルで作成する
次に、IStateインターフェースを実装する具体的な状態クラスを作成します。各クラスは別のファイルに分けて作成してください。
NormalState.cs
public class NormalState : IState
{
public string Handle()
{
return "キャラクターは通常状態です。";
}
}AttackingState.cs
public class AttackingState : IState
{
public string Handle()
{
return "キャラクターは攻撃しています！";
}
}DefendingState.cs
public class DefendingState : IState
{
public string Handle()
{
return "キャラクターは防御しています！";
}
}3. Characterクラスを作成する
キャラクターの状態を管理し、状態に応じた動作を実行するCharacterクラスを作成します。
public class Character
{
public string Name { get; set; }
public IState CurrentState { get; set; }
public Character(string name, IState initialState)
{
Name = name;
CurrentState = initialState;
}
public string PerformAction()
{
return $"{Name}は{CurrentState.Handle()}";
}
}4. Form1クラスを更新する
最後に、Form1クラスをStateパターンに合わせて更新します。
public partial class Form1 : Form
{
private Character character;
public Form1()
{
InitializeComponent();
comboBox1.Items.Add("Normal");
comboBox1.Items.Add("Attacking");
comboBox1.Items.Add("Defending");
character = new Character("勇者", new NormalState());
}
private void button1_Click(object sender, EventArgs e)
{
switch (comboBox1.SelectedItem.ToString())
{
case "Normal":
character.CurrentState = new NormalState();
break;
case "Attacking":
character.CurrentState = new AttackingState();
break;
case "Defending":
character.CurrentState = new DefendingState();
break;
}
string result = character.PerformAction();
MessageBox.Show(result);
}
}ステップ5: 振り返りと応用
Stateパターンを導入したことで、状態が増えた場合でも、簡単に新しいクラスを作成するだけで対応できるようになりました。また、Characterクラスのコードが非常にシンプルになり、他の動作にも応用が利く設計になりました。
振り返り
- 柔軟な設計: 新しい状態を追加する際に、既存のコードをほとんど変更せずに済むため、柔軟な設計が可能です。
- コードの分離: 各状態が独立したクラスに分かれているため、コードの見通しが良く、保守性が向上しました。
応用例
このパターンは、キャラクターの状態に限らず、他の選択肢や動作を切り替えるシーンでも使えます。例えば、キャラクターの行動パターンやゲームシステム全体のフェーズ管理などにも応用できます。
このチュートリアルを通じて、シンプルな設計からデザインパターンを導入するプロセスを学び、より柔軟で拡張性のあるコードを書けるようになりましょう。
状態を列挙型で定義する方法との違いは？
状態を列挙型（enum）で定義する方法とStateパターンの違いについて説明します。どちらもオブジェクトの状態を管理するために使用できますが、適用する場面や目的が異なります。
状態を列挙型で定義する方法
列挙型（enum）を使った状態管理は、状態が比較的シンプルで、状態ごとに異なるロジックを管理する必要がない場合に適しています。以下はその特徴です。
特徴
シンプルさ: 状態を列挙型で表現するのは非常にシンプルです。列挙型を使うことで、状態を一意に識別しやすくなります。
switch文やif文での処理: 列挙型を使用する場合、状態に応じた処理をswitch文やif文で記述することが多いです。例えば、次のようになります。
public enum CharacterState
{
Normal,
Attacking,
Defending
}public void PerformAction(CharacterState state)
{
switch (state)
{
case CharacterState.Normal:
Console.WriteLine("キャラクターは通常状態です。");
break;
case CharacterState.Attacking:
Console.WriteLine("キャラクターは攻撃しています！");
break;
case CharacterState.Defending:
Console.WriteLine("キャラクターは防御しています！");
break;
}
}状態に応じた分岐が増える: 状態が増えるたびに、switch文やif文に新しいケースを追加する必要があります。これにより、コードの複雑さが増し、メンテナンスが難しくなる可能性があります。
状態に応じた振る舞いの集中: 状態ごとの処理が一箇所に集中するため、コードの再利用性や拡張性が低くなります。処理が追加・変更されるたびに、既存のコードを変更するリスクが高まります。
Stateパターン
Stateパターンは、オブジェクトの状態をクラスとしてカプセル化し、状態に応じた振る舞いをそれぞれのクラスで実装するデザインパターンです。以下がStateパターンの特徴です。
特徴
- クラスの責任分担: 各状態が独立したクラスとして定義されるため、状態ごとの処理がカプセル化され、クライアントコードから分離されます。これにより、状態ごとの振る舞いが明確になり、メンテナンスが容易になります。
- 動的な状態変更: 状態オブジェクトが動的に変更され、オブジェクトの振る舞いがリアルタイムに変わります。Stateパターンでは、クライアントコードは状態の変更だけを管理し、その後の処理は状態オブジェクトに委譲されます。
- オープン・クローズド原則の遵守: 新しい状態を追加する場合、新しい状態クラスを作成するだけで、既存のコードには影響を与えません。これにより、拡張性が高く、既存コードの変更リスクが低減されます。
- コードの分散: 各状態の処理が個別のクラスに分かれているため、状態ごとの処理が一箇所に集中せず、コードの再利用性が向上します。
列挙型 vs Stateパターン
| 比較項目 | 列挙型（enum） | Stateパターン |
|---|---|---|
| シンプルさ | シンプルで分かりやすい。状態の数が少ない場合に有効。 | クラスの数が増えるため複雑だが、柔軟性が高い。 |
| 拡張性 | 状態が増えるとswitch文やif文が肥大化し、メンテナンスが困難に。 | 新しい状態を追加しても既存コードに影響が少ない。 |
| コードの分散 | 状態ごとの処理が集中し、変更のたびに既存コードを変更する必要がある。 | 状態ごとの処理が独立し、再利用性と保守性が向上。 |
| 動的な状態変更 | 列挙型の値が変わるだけで、コードの再実行が必要。 | 状態オブジェクトを動的に変更できるため、動作がリアルタイムで変わる。 |
| 責任の分離 | 状態の処理が単一のメソッド内に集約される。 | 状態ごとにクラスが分かれ、責任が明確になる。 |
まとめ
列挙型を使用した状態管理は、簡単で手軽に実装できるため、状態が少なく複雑な振る舞いがない場合に適しています。一方で、Stateパターンは、状態が増えたり複雑な振る舞いを管理する必要がある場合、拡張性や保守性を高めるために適した設計です。どちらを使用するかは、システムの規模や将来的な拡張性を考慮して選択することが重要です。