Hackを掌握する極限の知見：Enum Classとパターンマッチングで実現する「コンパイル時・網羅性完全保証」の状態遷移設計
テックリードの私だ。コードレビューをしていて、未だに以下のようなコードを見かけるたびに頭を抱えている。
// 愚かなコードの例：文字列による状態管理と、漏れだらけのswitch
function handle_order_legacy(string $status): void {
switch ($status) {
case ‘pending’:
// 処理…
break;
case ‘shipped’:
// 処理…
break;
// 誰かが新しいステータス ‘delivered’ を追加した瞬間、このswitch文は黙ってスルーするかバグを産む
default:
throw new \Exception(“Unknown status”);
}
}
「動的言語のノリ」をHackの静的型付きの世界に持ち込むのは今すぐやめてもらいたい。
文字列やマジックナンバーで状態を表現し、`default` 句に例外を投げるだけのコードは、将来の障害予約チケットに他ならない。
今回は、Hack言語が誇る最強の武器である `Enum Class` と パターンマッチング（`is` / `as` 表現、あるいは今後の進化を見据えた構造化制御） を組み合わせ、「新しい状態を追加した瞬間に、型チェッカーが未処理のケースを検知してビルドを落とす」 という、バグの入り込む余地のない堅牢な状態遷移システムの設計論を叩き込む。
—
1. なぜ従来のEnumや文字列では不十分なのか
PHPや旧来の言語におけるEnumは、単なる「名前付きの定数の集合」にすぎない。
しかし、Hackの `Enum Class` は、型安全なメタプログラミングと値の制約を同時に満たす、極めて高度な抽象概念だ。
HHVMの型チェッカー（Typechecker）は、Strictモード（`<<__STRICT__>>`）下において、コードの隅々まで型と値のフローを追跡している。
状態遷移における最大のバグは「状態が増えたときに、処理の分岐を書き忘れること」だ。これをランタイムのエラーではなく、静的解析（コンパイル時）の段階で100%コンパイルエラーとして検出させるのが、プロのエンジニアの仕事である。
—
2. 実践：Enum Classによる型安全な状態遷移の構築
では、Eコマースの注文ステータスを題材に、プロダクションコードレベルの設計を見ていこう。
以下のコードは、そのまま君たちのシステムに組み込めるクオリティで書いている。
<<__STRICT__>>
namespace App\Order;
/
- 注文ステータスを定義するEnum Class
- 各状態に付随するメタデータや振る舞いの制約を型レベルで強制する。
/
enum class OrderStatus: string {
Pending = ‘PENDING’;
Paid = ‘PAID’;
Shipped = ‘SHIPPED’;
Delivered = ‘DELIVERED’;
Canceled = ‘Canceled’;
}
/
- 状態遷移のバリデーションと処理をカプセル化するコンテキスト
/
final class OrderStateMachine {
private OrderStatus $currentStatus;
public function __construct(OrderStatus $initialStatus) {
$this->currentStatus = $initialStatus;
}
public function getStatus(): OrderStatus {
$this->currentStatus;
}
/
- 遷移先の妥当性を検証し、状態を更新する
/
public function transitionTo(OrderStatus $nextStatus): void {
if (!$this->isAllowedTransition($this->currentStatus, $nextStatus)) {
throw new \InvalidArgumentException(
\Str\format(‘Invalid state transition from %s to %s’,
HH\Asio\join($this->formatStatus($this->currentStatus)),
HH\Asio\join($this->formatStatus($nextStatus))
)
);
}
$this->currentStatus = $nextStatus;
}
/
- 状態遷移マトリクス（ここで網羅性とルールを定義する）
/
private function isAllowedTransition(OrderStatus $from, OrderStatus $to): bool {
// パターンマッチング的なアプローチによる厳密なマトリクス判定
return match ($from) {
OrderStatus::Pending =>
$to === OrderStatus::Paid || $to === OrderStatus::Canceled,
OrderStatus::Paid =>
$to === OrderStatus::Shipped || $to === OrderStatus::Canceled,
OrderStatus::Shipped =>
$to === OrderStatus::Delivered,
OrderStatus::Delivered, OrderStatus::Canceled =>
false, // 終端状態からの遷移は一切許容しない
};
}
private async function formatStatus(OrderStatus $status): Awaitable
return $status;
}
}
この設計の美しさと優位性
1. 網羅性チェック（Exhaustiveness Checking）の強制:
`match` 式を使用している点に注目してほしい。Hackの `match` 式は、対象となるEnumのすべてのケースが網羅されているかを型チェッカーが厳格に検証する。
もし将来、`OrderStatus` に `Refunded` が追加された場合、上の `match` 式にケースを追加し忘れると、型チェッカーが即座にビルドエラーを吐く。これにより、「仕様変更漏れ」というヒューマンエラーを物理的にシャットアウトできる。
2. マジックストリングの排除:
文字列比較によるバグ（大文字小文字のミス、タイポなど）が型レベルで根絶される。IDEの補完も完璧に効くため、開発体験（DX）も圧倒的に向上する。
—
3. パフォーマンスとHHVMアーキテクチャの裏側
「こんなに厳格な型チェックやオブジェクト指向的なラップをして、HHVMのパフォーマンスに影響はないのか？」という懸念を持つシニアエンジニアもいるだろう。
結論から言えば、心配無用だ。むしろ逆である。
- JITコンパイルの最適化:
HHVMのJIT（Just-In-Time）コンパイラは、型が厳格に保証されているコード（Strict Mode）において最も効率的なネイティブコードを生成する。型が確定しているため、動的なプロパティルックアップやハッシュマップの引けが発生せず、C/C++並みのインライン展開や最適化の恩恵を受けられる。
- Enum Classの内部表現:
HackのEnum Classは、実行時には軽量なプリミティブ値（今回の場合は `string`）または最適化された内部構造として扱われるため、過剰なメモリオーバーヘッドを懸念する必要はない。
—
4. コードレビューにおけるチェックポイント
今後、チームメンバーから今回のような状態管理に関するPR（プルリクエスト）が上がってきたら、以下のポイントを必ず確認せよ。
- [ ] `if-else` の連続になっていないか？: 状態の分岐には必ず `match` 式を使用し、型チェッカーに網羅性を強制させているか。
- [ ] `default` 句に逃げていないか？: `default` を使うことは「新しい状態の追加を無視するバグ」を生む温床になるため、原則としてEnumの網羅時は `default` を排除せよ。
- [ ] 状態と振る舞いが分離しすぎていないか？: 状態（Data）とそこから許可される遷移（Logic）がドメインモデルの近傍にカプセル化されているか。
最後に：プログラマの怠惰を、型の力で補正せよ
我々は人間である以上、仕様変更があったときに「あ、あっちのファイルの分岐も書き換えなきゃいけないんだっけ？」と忘れる生き物だ。その忘却リスクを、自分の記憶力でカバーしようなどと傲慢になってはならない。
「コンパイラ（型チェッカー）に怒られる仕組みをコードベースに埋め込むこと」こそが、優れたアーキテクトの仕事であり、真に保守性の高いシステムを維持する唯一の解である。
今日の学びを即座に持ち帰り、プロダクションコードの `switch` と `default` を根絶やしにしてくれ。健闘を祈る。