【実務・中級編】【中級者向け】`Enum Class`によるステートマシンの実装：定数管理を超えた網羅的チェックの活用 – Hack言語コア・静的型システムとHHVMのアーキテクチャ解析バイブル

Enum Classの真価：型チェッカーを武器にする堅牢なステートマシン設計

コードレビューをしていて、いまだに文字列や整数のマジックナンバーで状態遷移を管理しているコードを見ると、私はこう問いたくなる。「そのif文の網羅性、誰が保証するのか」と。

動的言語出身者がやりがちな「とりあえず文字列で状態を持たせておく」という設計は、大規模なWebアプリケーションにおいて技術的負債の温床になる。状態が増えた瞬間に数多のswitch文やif-elifの連鎖が崩壊し、本番環境で未定義のステートが爆発する――君たちも一度や二度は経験があるはずだ。

HHVMの厳格な静的型システム（Strict Mode）とHack言語が誇る `Enum Class` を使えば、こうしたランタイムの絶望をコンパイル時の安心感へと完全に変換できる。今回は、単なる「定数まとめ」としての使い方を超え、型チェッカーに状態遷移の正当性を強制させるプロダクションレベルの設計パターンを伝授しよう。

—

なぜ従来のEnumではステートマシンとして不十分なのか？

従来の `enum` は、単なるプリミティブ型（intやstring）のエイリアスに過ぎない。そのため、異なるコンテキストで定義されたEnum同士が混ざり合っても、型チェッカーがそれを静的に弾ききれないケースが存在した。また、メタデータを付与したり、状態ごとの関連型（Associated Types）を厳密に縛り付けることができなかった。

ここで登場するのが `Enum Class` だ。
Enum Classは、個々の列挙子が「オブジェクト」として振る舞い、かつそれぞれが独自の型を持つ。つまり、「どの状態の時に、どのようなデータ構造（ペイロード）を内包していなければならないか」を型レベルで完全に制約できる。

ステートマシンにおいて、これは強力な武器になる。なぜなら、「処理待ち状態」の時には「未処理のペイロード」が存在し、「完了状態」の時には「結果データ」が存在するという状態とデータの不可分性を、型チェッカーに強制できるからだ。

—

実装：Enum Classによる型安全なステートマシン

百聞は一見にしかず。注文（Order）のライフサイクルを管理するステートマシンを、Strict Modeかつ無駄のないHHVM最適化を意識したコードで実装してみよう。

namespace App\StateMachine;

注文ステートマシンのメタデータと型を定義するEnum Class

/
enum class OrderState: mixed {
// 各ステートが持つべきペイロードの型をここでジェネリクス的に束縛する
Pending(PendingPayload);
Processing(ProcessingPayload);
Completed(CompletedPayload);
Cancelled(CancelledPayload);
}

// — 各状態のペイロード（不変データ構造） —
data class PendingPayload(readonly int customerId, readonly vec itemIds);
data class ProcessingPayload(readonly int customerId, readonly string workerId);
data class CompletedPayload(readonly int customerId, readonly float totalAmount);
data class CancelledPayload(readonly int customerId, readonly string reason);

状態遷移を司るコンテキストクラス

/
<<__ConsistentConstruct>>
final class OrderContext {
private function __init__(
private OrderState $state,
private mixed $payload,
) {}

public static function create(int $customer, vec items): this {
$payload = new PendingPayload($customer, items);
return new static(OrderState::Pending, $payload);
}

型安全な状態遷移メソッド
実行時の条件分岐だけでなく、遷移元と遷移先の整合性を担保する

/
public function transitionToProcessing(string $workerId): OrderContext {
// 現在の状態が Pending であることを型レベル・値レベルで確認
$currentPayload = $this->assertStateAndGetPayload(OrderState::Pending);

$newPayload = new ProcessingPayload($currentPayload->customerId, $workerId);
return new static(OrderState::Processing, $newPayload);
}

public function transitionToCompleted(float $amount): OrderContext {
$currentPayload = $this->assertStateAndGetPayload(OrderState::Processing);

$newPayload = new CompletedPayload($currentPayload->customerId, $amount);
return new static(OrderState::Completed, $newPayload);
}

内部アサーション：不正な遷移をコンパイル時、または厳格な実行時チェックで弾く

/
private function assertStateAndGetPayload(OrderState $expectedState): T {
// Enum Classのアイデンティティ比較
if ($this->state !== $expectedState) {
throw new \InvariantException(
Str\format(‘Invalid state transition. Expected %s, but currently in %s’,
HH\Asio\join(/ debug info /) … / 略 /)
);
}
// ここで型キャストの安全性が保証される
return Asio\join(/ … /) ?? / … /; // ※簡略化のため実務では適切にキャスト
}
}

—

パターンマッチングと網羅性チェック（Exhaustiveness）

Enum Classの真価は、状態に応じた振替処理を書く際のパターンマッチングの網羅性にある。
switch文やmatch式を書く際、もし新しい状態（例えば `Refunded`）を `OrderState` に追加したにもかかわらず、ハンドリングするコード側でそれを書き忘れた場合、どうなるべきか？

優秀なアーキテクトなら答えを知っているはずだ。「コンパイルエラー（Typechecker Error）になるべき」である。

Hack言語の型チェッカーは、すべてのEnum Classのバリアントが処理されているかを静的に検証する。以下のように `match` 式を構築せよ。

namespace App\StateMachine;

class OrderPresenter {
public static function getStatusDescription(OrderState $state): string {
// Hackの match 式。全てのEnum Classバリアントが網羅されていない場合、
// 型チェッカーが容赦なくエラーを吐く。
return match ($state) {
OrderState::Pending => ‘注文を受け付けました。処理をお待ちください。’,
OrderState::Processing => ‘現在倉庫にて出荷作業中です。’,
OrderState::Completed => ‘配送が完了しました。ご利用ありがとうございます。’,
OrderState::Cancelled => ‘この注文はキャンセルされました。’,
// もしここで新しいステートを追加し忘れると、hh_clientがビルドを即座に落とす。
};
}
}

この網羅性チェックの恩恵は計り知れない。機能追加のたびに「あそこのswitch文、修正し忘れてないか…？」と冷や汗をかくシニアエンジニアの姿は、もうこのチームには不要だ。型チェッカーが夜も昼も番人として君のコードを守ってくれる。

—

HHVMアーキテクチャの観点：パフォーマンスとメモリ効率の極意

さて、ここまで美しいコードを書いたところで、Hackerとしてのパフォーマンスへの執着を見せよう。
HHVM（HipHop Virtual Machine）は、HackコードをJIT（Just-In-Time）コンパイルし、ネイティブマシン語に変換することで爆発的なスループットを生み出す。しかし、オブジェクトの乱用はメモリのGarbage Collector（GC）に負荷をかける。

Enum Classを用いる際のパフォーマンス上の注意点を挙げておく。

1. ペイロードのイミュータビリティ（不変性）の徹底
データクラス（`data class`）を使用することで、各ペイロードはコピーオンライトまたは完全なイミュータブルとして扱われ、HHVMの内部アロケータで最適化されやすくなる。ミュータブルな状態をあちこちで書き換える設計にすると、JITの最適化効力が落ちるだけでなく、予期せぬ競走状態（Race Condition）の温床になる。

2. 不要なボックス化（Boxing）の回避
Enum Classの列挙子は静的に解決されるため、通常のオブジェクトインスタンス生成とは異なり、HHVMの類型化された内部構造（ArrayやDataType）の中で効率よくハンドリングされる。ただし、過剰にネストしたペイロード構造はポインタ追跡コストを増大させるため、ステートが保持するデータは「その状態に必要な最小限のコンテキスト」に絞り込むべきだ。

—

チーフアーキテクトからの提言

コードレビューの現場で、if文の嵐や `string $status` という緩い引数を見かけたら、こう指導してほしい。
「文字列で状態を表すな。それは設計の放棄だ」と。

Hackの厳格な静的型システムとEnum Classを組み合わせることで、「間違った状態遷移のコードを書くこと自体が不可能である世界」を構築できる。テストコードを書く以前に、コンパイラと型チェッカーが最大のテストスイートとして機能する――これこそが、モダンなWebエンジニアリングの到達点だ。

さあ、今すぐ既存のレガシーなステート管理をリファクタリングし、型チェッカーを君の最も頼れる相棒へと仕立て上げたまえ。