Stateパターン調査ドキュメント

調査概要

• 調査目的: Stateパターンの技術情報、実装例、ユースケースを調査し、記事作成の基礎資料を作成する
• 調査実施日: 2026年1月8日
• キーワード: Stateパターン、State pattern、デザインパターン、GoF
• 技術スタック: Perl / Moo

1. Stateパターンの基礎

1.1 定義と目的

要点:

• Stateパターンは、GoF（Gang of Four）の振る舞いパターン（Behavioral Patterns）の1つ
• 「オブジェクトの内部状態が変化したときに、その振る舞いを変化させる。オブジェクトはあたかもクラスを変えたかのように振る舞う」
• オブジェクトの状態に応じて振る舞いを切り替えることを可能にする
• 状態ごとの条件分岐（if/else、switch）を削減し、状態をオブジェクトとして分離する

根拠:

• GoF書籍「Design Patterns: Elements of Reusable Object-Oriented Software」（1994年）で定義
• Refactoring Guru、GeeksforGeeks、Wikipedia等の主要技術サイトで一致した説明

仮定:

• 読者はStrategyパターンを学習済み、または並行して学習中
• 「状態」と「振る舞い」の関係を理解する必要がある

出典:

• Wikipedia: State pattern - https://en.wikipedia.org/wiki/State_pattern
• Refactoring Guru: State - https://refactoring.guru/ja/design-patterns/state
• GeeksforGeeks: State Design Pattern - https://www.geeksforgeeks.org/system-design/state-pattern-set-1/
• Qiita: デザインパターン Stateパターン - https://qiita.com/AsahinaKei/items/ce8e5d7bc375af23c719

信頼度: 9/10（GoF原典および複数の信頼できる技術サイト）

1.2 構成要素（State、ConcreteState、Context）

Stateパターンは、以下の3つの主要コンポーネントで構成される。

	classDiagram
    class Context {
        -state: State
        +setState(State)
        +request()
    }
    class State {
        <<interface>>
        +handle(Context)
    }
    class ConcreteStateA {
        +handle(Context)
    }
    class ConcreteStateB {
        +handle(Context)
    }
    class ConcreteStateC {
        +handle(Context)
    }
    
    Context o--> State : has
    ConcreteStateA ..|> State : implements
    ConcreteStateB ..|> State : implements
    ConcreteStateC ..|> State : implements

要点:

• Contextは状態の詳細を知らない（疎結合）
• ConcreteStateがContextへの参照を持ち、状態遷移を制御することが多い（Strategyとの重要な違い）
• 状態遷移ロジックは各ConcreteStateに分散される

根拠:

• GoF書籍の構造定義
• TECHSCORE、IT専科等のデザインパターン解説サイト

出典:

• TECHSCORE: State パターン - https://www.techscore.com/tech/DesignPattern/State
• IT専科: State パターン - https://www.itsenka.com/contents/development/designpattern/state.html
• Refactoring Guru: State - https://refactoring.guru/ja/design-patterns/state

信頼度: 9/10

1.3 メリット・デメリット

メリット

デメリット

根拠:

• 複数の技術記事・Stack Overflowでの議論
• Qiita、Zenn等での実践報告

出典:

• Qiita: GoF 23パターン State編 - https://qiita.com/Pentaro256/items/752f28aa425c4295b13d
• Zenn: デザインパターンを学ぶ #17 ステート（State） - https://zenn.dev/tajicode/articles/aa18feba9a570f

信頼度: 9/10

1.4 Stateパターンが有効なユースケース

要点:

適用すべきでない場面:

• 状態が1〜2個で今後も増えない見込み
• 状態間の差異がほとんどない
• 状態遷移ルールがシンプルで固定的
• 追加クラスによる複雑さがメリットを上回る

信頼度: 9/10

2. 類似パターンとの比較

2.1 Stateパターン vs Strategyパターンの違い

選択指針:

• 「オブジェクトの状態によって振る舞いを変えたい」＋「状態遷移がある」 → State
• 「どう処理するか（アルゴリズム）を切り替えたい」＋「外部から選択」 → Strategy

根拠:

• GoF書籍での定義
• 両パターンの構造は似ているが、意図と責任が異なる

出典:

• Baeldung: State vs Strategy Pattern - https://www.baeldung.com/cs/design-state-pattern-vs-strategy-pattern
• GeeksforGeeks: Difference Between State and Strategy - https://www.geeksforgeeks.org/java/difference-between-state-and-strategy-design-pattern-in-java/
• Qiita: Strategy パターン vs State パターン - https://qiita.com/nozomi2025/items/fa8032646baaee72b15d
• Zenn: Strategy Pattern と State Pattern - https://zenn.dev/waffledog/scraps/4eb0b97454b07a
• ソフトライム: StrategyパターンとStateパターンの違い - https://soft-rime.com/post-18061/

信頼度: 9/10

2.2 他の振る舞いパターンとの関係

信頼度: 9/10

3. Stateパターンの実装例

3.1 一般的な実装パターン

信号機の例（状態遷移図）

1
2
3

[赤信号] --(時間経過)--> [青信号]
[青信号] --(時間経過)--> [黄信号]
[黄信号] --(時間経過)--> [赤信号]

Javaでの基本実装例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

// State インターフェース
public interface TrafficLightState {
    void showSignal();
    void next(TrafficLight trafficLight);
}

// ConcreteState: 赤信号
public class RedState implements TrafficLightState {
    @Override
    public void showSignal() {
        System.out.println("赤信号：止まってください");
    }
    @Override
    public void next(TrafficLight trafficLight) {
        trafficLight.setState(new GreenState());
    }
}

// ConcreteState: 青信号
public class GreenState implements TrafficLightState {
    @Override
    public void showSignal() {
        System.out.println("青信号：進んでください");
    }
    @Override
    public void next(TrafficLight trafficLight) {
        trafficLight.setState(new YellowState());
    }
}

// Context
public class TrafficLight {
    private TrafficLightState currentState;
    
    public TrafficLight() {
        this.currentState = new RedState();
    }
    
    public void setState(TrafficLightState state) {
        this.currentState = state;
    }
    
    public void showSignal() {
        currentState.showSignal();
    }
    
    public void change() {
        currentState.next(this);
    }
}

出典:

• Qiita: Stateパターン - https://qiita.com/Yankaji777/items/c70afa09f3c1cc2de0b6
• tamotech.blog: 「State」パターンとは？ - https://tamotech.blog/2025/05/13/state/

信頼度: 9/10

3.2 Perlでの実装アプローチ（Moo/Mooseを使った場合）

要点:

• PerlではMoo::Roleを「State インターフェース」として使用
• requiresで必須メソッドを定義し、各ConcreteStateクラスがRoleを消費（with）
• StateがContextへの参照を持ち、状態遷移を制御する

コード例:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104

# State Role（インターフェース）
package VendingMachineState;
use Moo::Role;
requires 'insert_coin';
requires 'select_product';
requires 'dispense';
1;

# ConcreteState A: 待機状態
package WaitingState;
use Moo;
use v5.36;
with 'VendingMachineState';

sub insert_coin ($self, $context) {
    say "コインを受け付けました";
    $context->set_state(CoinInsertedState->new);
}

sub select_product ($self, $context) {
    say "先にコインを入れてください";
}

sub dispense ($self, $context) {
    say "商品を払い出せません";
}
1;

# ConcreteState B: コイン投入済み状態
package CoinInsertedState;
use Moo;
use v5.36;
with 'VendingMachineState';

sub insert_coin ($self, $context) {
    say "既にコインが入っています";
}

sub select_product ($self, $context) {
    say "商品を選択しました";
    $context->set_state(DispensingState->new);
}

sub dispense ($self, $context) {
    say "先に商品を選んでください";
}
1;

# ConcreteState C: 払い出し状態
package DispensingState;
use Moo;
use v5.36;
with 'VendingMachineState';

sub insert_coin ($self, $context) {
    say "払い出し中です。お待ちください";
}

sub select_product ($self, $context) {
    say "払い出し中です。お待ちください";
}

sub dispense ($self, $context) {
    say "商品を払い出しました";
    $context->set_state(WaitingState->new);
}
1;

# Context: 自動販売機
package VendingMachine;
use Moo;
use v5.36;

has state => (
    is      => 'rw',
    default => sub { WaitingState->new },
);

sub set_state ($self, $state) {
    $self->state($state);
}

sub insert_coin ($self) {
    $self->state->insert_coin($self);
}

sub select_product ($self) {
    $self->state->select_product($self);
}

sub dispense ($self) {
    $self->state->dispense($self);
}
1;

# 使用例
package main;
use v5.36;

my $machine = VendingMachine->new;
$machine->insert_coin;      # コインを受け付けました
$machine->select_product;   # 商品を選択しました
$machine->dispense;         # 商品を払い出しました
$machine->select_product;   # 先にコインを入れてください

根拠:

• Moo::Roleのrequiresで必須メソッドを宣言でき、実装漏れを防げる
• Strategyパターンとの違い：StateがContext（$self）を受け取り、状態遷移を制御する

出典:

• MetaCPAN: Moo::Role - https://metacpan.org/pod/Moo::Role
• MetaCPAN: Moo - https://metacpan.org/pod/Moo
• Perl Maven: OOP with Moo - https://perlmaven.com/oop-with-moo
• Moose::Manual::Concepts - https://perldoc.jp/pod/Moose::Manual::Concepts

信頼度: 9/10

4. 競合記事の分析

4.1 日本語の主要記事

4.2 差別化ポイントの抽出

既存記事の問題点:

1. Perl/Moo特化の記事が皆無: 日本語でPerl向けのState解説はほぼ存在しない
2. Strategyとの比較が不十分: 構造が似ているため混同しやすいが、違いの説明が曖昧
3. 状態遷移図との連携不足: コードだけで状態遷移を説明しがち
4. 実践的なユースケースの不足: 抽象的な例が多い

本教材シリーズの強み（予定）:

1. Perl/Moo特化: v5.36対応のモダンPerl記法
2. Strategyパターンとの明確な比較: 既存のStrategyシリーズとの連携
3. 状態遷移図との併用: Mermaidで視覚化
4. 段階的な学習: 「Mooで覚えるオブジェクト指向プログラミング」からの継続性
5. 実践的な題材: 自動販売機など身近な例

信頼度: 9/10

5. 内部リンク調査

5.1 関連記事（grep調査結果）

State/ステート関連のヒット

Strategy/ストラテジー関連のヒット（比較用）

デザインパターン関連のヒット

Moo/オブジェクト指向関連のヒット

5.2 推奨内部リンク一覧

前提知識記事

比較・関連記事

6. 既存シリーズとの重複チェック

6.1 /agents/structure/ 配下の既存シリーズ構造

6.2 重複チェック結果

Stateパターンを扱った既存シリーズ: なし

既存のシリーズ構造案にStateパターンを主題としたものは存在しない。

7. まとめ

7.1 調査結果のサマリー

1. Stateパターンの位置づけ: GoF振る舞いパターンの1つ。Strategyパターンと構造は似ているが、目的と切り替え主体が異なる

2. Strategyとの主な違い:

   • State: 内部状態の変化に応じて自動で切り替え、状態遷移あり
   • Strategy: 外部から明示的にアルゴリズムを選択

3. Perl/Moo実装の可能性: Moo::Roleで状態インターフェースを定義し、各ConcreteStateがContextへの参照を持って状態遷移を制御する設計が可能

4. 既存シリーズとの重複: Stateパターンを扱った既存シリーズはなし

参考文献・リソースリスト

書籍

Webリソース

調査完了日: 2026年1月8日 調査者: 調査・情報収集エージェント

End of Document