Enum Classという名の「型安全な要塞」：Hackにおける状態遷移の極致
Hackを触っている君たちなら、従来の `enum` が単なる「定数の集合」に過ぎないという事実に、一度は限界を感じたことがあるはずだ。型安全と言いつつも、結局は `match` 式で網羅性を保証するだけの、静的なラベル。
しかし、我々が目指しているのは「単なる値の列挙」ではない。「状態（State）という名のビジネスロジックそのものを、コンパイル時に型チェッカーで検証可能な鉄壁の構造体に落とし込むこと」だ。
今日話すのは、Hackの `Enum Class` を使ったステートマシンの構築論だ。これは単なるリファクタリングではなく、アーキテクチャの質を一段引き上げるための「型による設計」そのものだ。
—
1. なぜ従来の `enum` では不十分なのか
従来の `enum` は「値」をラップする。一方で `Enum Class` は「型」を包含する。
`Enum Class` の真の力は、「定数ごとに異なるデータ構造（ペイロード）を持たせられること」にある。例えば、注文ステータスにおいて「出荷済み」状態のときだけ「配送ID」が必要だとしたら、従来の enum では nullable なプロパティを全ステータスで共有せざるを得ない。これは型安全とは呼べない、ただの設計の妥協だ。
2. 状態遷移を型で縛り上げる：実務実装パターン
非同期API連携を伴う複雑なワークフローを想定しよう。`Pending` から `Processing`、そして `Completed` または `Failed` への遷移を、型システムで厳格に記述する。
<
// 状態遷移の基底となるEnum Class
enum class OrderStatus : mixed {
// ペイロードを型として定義可能
case Pending;
case Processing(int); // 処理開始タイムスタンプを持つ
case Completed(string); // 完了時の決済IDを持つ
case Failed(string); // エラーメッセージを持つ
}
/
- 状態遷移を管理するステートマシン
- 不正な遷移をコンパイル時に検知可能にする
/
final class OrderStateMachine {
private OrderStatus $status = OrderStatus::Pending;
// 遷移の許可を型で表現する
public function transitionToProcessing(int $timestamp): void {
if ($this->status is OrderStatus::Pending) {
$this->status = OrderStatus::Processing($timestamp);
} else {
throw new Exception(“Invalid transition from ” . $this->status::class);
}
}
// 網羅的な処理を強制する
public function handle(): void {
$status = $this->status;
match ($status) {
OrderStatus::Pending => $this->log(“待機中”),
OrderStatus::Processing($ts) => $this->log(“処理中: 開始時刻 {$ts}”),
OrderStatus::Completed($id) => $this->log(“完了: 決済ID {$id}”),
OrderStatus::Failed($msg) => $this->log(“失敗: {$msg}”),
};
}
private function log(string $msg): void {
print($msg . PHP_EOL);
}
}
この設計の鋭さ
1. データと状態の完全な結合: `Processing` 状態であるという型（型コンテキスト）を得た瞬間、自動的に `int` 型のタイムスタンプが安全に取り出せる。`null` チェックの迷宮とは無縁だ。
2. 網羅性の強制: `match` 式を用いることで、新しい状態が追加された際にコンパイラが「処理が足りていない」と警告を出す。リファクタリング時の破壊的な変更を即座に特定できる。
—
3. HHVMアーキテクチャとパフォーマンスの真実
「Enum Classは複雑なインスタンスを生成するから遅いのでは？」と懸念する声が聞こえてきそうだが、ここでHHVMのコアの話をしよう。
HHVMの型チェッカーとJITコンパイラは、`Enum Class` を非常に効率的な内部表現へ変換する。特に、固定された型の値に対しては、メモリレイアウトが最適化され、無駄なボックス化（Boxing）は最小限に抑えられる。
むしろ、「型チェックをサボって実行時に `is_null()` を繰り返すコスト」の方が、CPUの分岐予測を破壊し、メモリの局所性を低下させる。`Enum Class` は、型チェッカーが静的に解析した情報をランタイムの最適化に直接還元できるため、実は実行効率も最高峰だ。
—
4. プロダクションコードにおける運用の鉄則
現場でこの設計を導入する際の、私からの3つのアドバイスだ。
- 「状態遷移の純粋性」を保て: 状態遷移ロジックの中に外部通信を直接書くな。状態遷移関数は、状態と入力を受け取って新しい状態を返す「純粋関数」に近づけるべきだ。
- Enum Classの肥大化を避けよ: 1つのEnum Classにロジックを詰め込みすぎないこと。状態が多すぎる場合は、ドメインごとにEnum Classを分割し、それらを組み合わせる設計へ移行せよ。
- 型推論を過信しない: 明示的に型を記述することで、読み手（将来の君自身を含む）に対するドキュメントとしての価値を高めろ。特に複雑な遷移ロジックでは、型定義こそが最強の仕様書となる。
—
最後に：型は「制約」ではなく「武器」である
多くのエンジニアは、型を「書かなければならない義務」と考えている。しかし、Hackを極める者は知っている。型とは、バグが入り込む余地を物理的に消し去り、開発者の脳内メモリを解放するための最強の武器であると。
今日紹介した `Enum Class` によるステートマシンは、その序章に過ぎない。君たちのコードベースに、この「論理的な厳格さ」を注入してほしい。そうすれば、深夜のデバッグに追われる時間は劇的に減り、より高次元なプロダクトの設計に時間を割けるようになるはずだ。
Hackは、君たちの設計意図を最も正確に理解し、それを守り抜く言語だ。そのポテンシャルを使いこなせ。コードレビューでまた会おう。