こんにちは！Hack言語の世界へようこそ。チーフアーキテクトの私です。
他の言語（例えばPHPやTypeScriptなど）からHackの世界に飛び込んできた開発者の多くが、最初にその厳格さに驚き、そしてその美しさに魅了されます。特にHackの真骨頂であるStrict Mode（厳格モード）と、型チェッカーがもたらす安心感は、一度味わうと抜け出せなくなるほどの魔力を持っています。
今回は、そんなHackの型システムとHHVMの裏側の挙動を味方につけ、バグを文字通り「コンパイルエラー」で駆逐するための強力な武器、「Enum Class」と「パターンマッチング（Pattern Matching）」を組み合わせた状態遷移（ステートマシン）の極意を伝授しますね。
ここをクリアすれば、Hackの型システムの基本はバッチリマスターできますよ！一緒に紐解いていきましょう。
—
1. なぜ「状態遷移」でバグが起きるのか？
Webアプリケーションの開発において、注文処理、ユーザーの認証状態、ドキュメントのワークフローなど、さまざまな「ステートマシン（状態遷移）」を実装する機会がありますよね。
例えば、「未払い（Pending）」→「支払い済み（Paid）」→「発送済み（Shipped）」というシンプルな注文の流れを考えてみましょう。
従来のPHPや動的言語では、これらを単なる文字列（`’pending’`, `’paid’`など）や、緩い定数で管理しがちです。
[ 注文作成 ] —> ( ‘pending’ ) —> 支払い処理 —> ( ‘paid’ ) —> 発送処理 —> ( ‘shipped’ )
│
└──> 不正な状態 ( ‘unknown_status’ ) に！
このような設計には、大きなリスクが潜んでいます。
- タイポ（打ち間違い）によるバグ（`’paided’` と書いてしまうなど）
- 存在しない状態への遷移
- 新しい状態を追加したときに、分岐処理（switch文など）の書き忘れによる「網羅性漏れ（Exhaustiveness gap）」
Runtime（実行時）までバグに気づけない、これが従来のコードの怖さです。しかし、Hackの型チェッカーとEnum Classを使えば、これらを静的解析の段階で100%コンパイルエラーとして検知できます。
—
2. Hackの「Enum Class」で状態を型安全に定義する
Hackには、単なる列挙型（Enum）を超えた、より表現力豊かな「Enum Class」という機能が備わっています。これを使うと、状態ごとに異なるデータ型を紐づけたり、型安全なメタデータを付与したりすることが可能です。
まずは、注文の状態遷移をEnum Classで美しく定義してみましょう。
<<__STRICT>>
namespace HackStateExample;
// 注文の状態を表すEnum Class
enum class OrderState: string {
// 各状態を定義。型は string
Pending string = “PENDING”;
Paid string = “PAID”;
Shipped string = “SHIPPED”;
Cancelled string = “CANCELLED”;
}
ここで重要なのは、`<<__STRICT>>` 宣言です。Hackのソースコードの先頭には必ずこれを置き、型チェッカーに一切の妥協を許さない厳格なチェックを強制します。
—
3. パターンマッチングと網羅的チェック（Exhaustiveness Check）
状態が定義できたら、次は「現在の状態に応じて適切な処理を行う」ロジックです。ここでHackのパターンマッチング（`match` 式）が登場します。
Hackの `match` 式は、単なる `switch` 文のシンタックスシュガーではありません。型チェッカーが「すべての状態が網羅されているか」を静的に検証してくれます。もし将来、新しい状態（例: `Refunded`）を追加したのに、このマッチ式の処理を書き忘れた場合、型チェッカーが親切に怒ってくれます（コンパイルエラーになります）。
それでは、実際のステートマシン処理のコードを見てみましょう。
<<__STRICT>>
namespace HackStateExample;
class OrderProcessor {
// 現在の状態を受け取り、次のアクションを決定する
public static function getNextAction(OrderState $state): string {
// match 式によるパターンマッチング
return match ($state) {
// Enum Classのメンバーをそのまま指定
OrderState::Pending => “支払いを完了させてください”,
OrderState::Paid => “商品の発送準備を進めています”,
OrderState::Shipped => “商品は配送中です”,
OrderState::Cancelled => “この注文はキャンセルされました”,
// ※もしここでどれか一つでも書き忘れると、
// 「Non-exhaustive match」というコンパイルエラーが即座に発生します！
};
}
}
このコードの美しさが伝わるでしょうか？
万が一、`OrderState` に新しい状態を追加した瞬間、HHVMの型チェッカー（hhvm）が「おい、`OrderProcessor::getNextAction` で新しい状態のハンドリングが抜けているぞ！」とビルドを止めてくれます。本番環境で「Undefined state exception」に怯える夜とは、今日でお別れです。
—
4. 状態遷移のバリデーションを型に閉じ込める
さらに踏み込んで、「不正な状態遷移（例: Shipped から Pending に戻るなど）」すらも型レベル、あるいは堅牢なドメインロジックで弾く設計を見てみましょう。
<<__STRICT>>
namespace HackStateExample;
class Order {
private OrderState $state;
public function __construct(OrderState $initial_state) {
$this->state = $initial_state;
}
// 状態を安全に遷移させるメソッド
public function transitionTo(OrderState $new_state): void {
// 遷移のルールをパターンマッチで検証
$is_valid = match ($this->state) {
OrderState::Pending =>
$new_state === OrderState::Paid || $new_state === OrderState::Cancelled,
OrderState::Paid =>
$new_state === OrderState::Shipped || $new_state === OrderState::Cancelled,
// Shipped や Cancelled からはどこにも遷移できない（終端状態）
OrderState::Shipped, OrderState::Cancelled => false,
};
if (!$is_valid) {
throw new \InvalidArgumentException(
“Invalid state transition from {$this->state} to {$new_state}”
);
}
$this->state = $new_state;
}
}
この実装では、`Shipped` や `Cancelled` が `match` 式の複数のパターン（カンマ区切り）でエレガントにまとめられています。HHVMのJITコンパイラは、このような構造化された分岐を非常に効率よく最適化するため、実行性能のオーバーヘッドも極小に抑えられます。
—
5. まとめ：Hackの型システムがもたらす開発体験
今回は、Hackの `Enum Class` と `パターンマッチング` を駆使した、型安全なステートマシンの実装方法を解説しました。
- Strict Mode (`<<__STRICT>>`) で曖昧さを完全に排除する
- Enum Class でドメインの「状態」を厳密に定義する
- Match 式の網羅的チェックで、将来の改修漏れ（ヒューマンエラー）を静的に防ぐ
これらを組み合わせることで、「動かすまでバグがわからない」という不安から解放され、「コンパイルが通るなら、仕様通りに正しく動くはずだ」という確信を持ってコードを書けるようになります。
HHVMの圧倒的な実行速度と、この鉄壁の静的型システムが手に入るHack言語は、大規模なシステム開発において最高のパートナーとなります。ぜひ、あなたのプロジェクトのステートフルなロジックにも取り入れてみてくださいね。
それでは、次回の極限の知見でお会いしましょう！Happy Hacking!