Hackを掌握する極限の知見：Enum ClassとPattern Matchingで構築する「バグが入り込む余地のない」ステートマシン設計
コードレビューをしていて、最も辟易するのは何か。
「不正な状態遷移」を許容するガバガバな型定義、そして実行時例外（`BadMethodCallException` や `UnexpectedValueException`）のオンパレードだ。
「決済完了後にキャンセル処理が走る」
「未認証のユーザーが認可済みの非同期APIを叩ける」
こうしたシステム障害の多くは、動的言語の悪癖を引きずった「文字列や整数によるフラグ管理」と「不完全な条件分岐」が原因である。HHVMの型チェッカーを骨の髄まで理解していれば、これらはコンパイルエラーとして事前に完全駆逐できる。
今回は、Hack言語が誇る最強の武器である `Enum Class` と `Pattern Matching（match式）` を組み合わせ、実務の非同期API連携や複雑なコンポーネント設計において「バグの入り込む余地をゼロにする」堅牢なステートマシンの実装パターンを伝授する。
—
1. なぜ従来のEnumや状態管理では不十分なのか？
PHPや、妥協したHackコードで見かける典型的なアンチパターンを見てみよう。
// 【アンチパターン】文字列や数値のプリミティブで状態を管理する愚行
class OrderState {
const string CREATED = ‘created’;
const string PAID = ‘paid’;
const string SHIPPED = ‘shipped’;
}
このアプローチの問題点は明白だ。
1. 型安全性の欠如: 引数が単なる `string` であるため、任意の文字列が混入し得る。
2. 網羅性チェックの欠落: `switch` 文を書いた際、新しい状態を追加してもコンパイラが警告を出さないため、処理の抜け漏れ（バグ）が必ず発生する。
Hackの `Enum Class` は、単なる定数の集まりではない。型安全なメタプログラミングと値の結びつきを強烈に強制する、HHVMの静的解析の要である。
—
2. 実践：Enum Classによる厳格な状態定義
まずは、ECサイトの注文ライフサイクルを例に、遷移可能な状態と、それに付随するペイロード（データ）を型レベルで厳密に定義する。
// strict
<
namespace App\StateSystem;
// 注文ステートマシンの各状態をEnum Classで表現する
enum class OrderStatus: mixed {
// 各ケースに具体的な型をバインドする
Created = OrderPayloads::Created;
Paid = OrderPayloads::Paid;
Shipped = OrderPayloads::Shipped;
Cancelled = OrderPayloads::Cancelled;
}
// 各状態が保持すべきデータの構造（Shape）を定義
type CreatedData = shape(‘cart_id’ => string, ‘user_id’ => int);
type PaidData = shape(‘payment_id’ => string, ‘amount’ => int);
type ShippedData = shape(‘tracking_number’ => string, ‘carrier’ => string);
type CancelledData = shape(‘reason’ => string);
class OrderPayloads {
const type Created = CreatedData;
const type Paid = PaidData;
const type Shipped = ShippedData;
const type Cancelled = CancelledData;
}
ここで重要なのは、`OrderStatus` の各要素が単なるラベルではなく、「その状態特有のデータ構造（Payload）」と厳密に紐づいている点だ。これにより、不正なデータ構造を持つ状態の生成がコンパイル時に不可能になる。
—
3. Pattern Matching（match式）による網羅的チェック（Exhaustiveness Check）
状態が定義できたら、次は「状態の遷移」と「イベント処理」だ。
ここでHHVMの `match` 式（Pattern Matching）を使用する。Hackの `match` は、すべてのケースが網羅されているかを静的解析で強制する。新しい状態を追加した瞬間、対応する処理を書き忘れたコードはコンパイルエラーになる。これこそが真の「保守性の高いコード」である。
以下のプロダクションコードを見てほしい。コピペし、チームの基盤として即座に応用できる設計にしている。
<
namespace App\StateSystem;
// 状態遷移を管理するステートマシンエンジン
class OrderStateMachine {
private OrderStatus $currentStatus;
private mixed $currentPayload;
public function __construct(OrderStatus $status, mixed $payload) {
$this->currentStatus = $status;
$this->currentPayload = $payload;
}
/
- 非同期API連携や外部イベントトリガーによる状態遷移の実行
/
public function transition(OrderStatus $targetStatus, mixed $newPayload): this {
// 遷移の正当性バリデーション（ビジネスロジックの制約）
$this->assertValidTransition($this->currentStatus, $targetStatus);
// 状態を更新
$this->currentStatus = $targetStatus;
$this->currentPayload = $newPayload;
// 副作用（Webhook送信やログ記録など）の実行
$this->executeSideEffects($targetStatus, $newPayload);
return $this;
}
/
- 状態に応じた処理を網羅的に分岐（Pattern Matching）
/
public function handleCurrentState
// Hackのmatch式による完全網羅チェック
return match ($this->currentStatus) {
OrderStatus::Created => $createdHandler($this->currentPayload),
OrderStatus::Paid => $paidHandler($this->currentPayload),
OrderStatus::Shipped => $shippedHandler($this->currentPayload),
OrderStatus::Cancelled => $cancelledHandler($this->currentPayload),
};
}
private function assertValidTransition(OrderStatus $from, OrderStatus $to): void {
// 許可された遷移マトリクスを定義
$isValid = match ($from) {
OrderStatus::Created => ($to === OrderStatus::Paid || $to === OrderStatus::Cancelled),
OrderStatus::Paid => ($to === OrderStatus::Shipped || $to === OrderStatus::Cancelled),
OrderStatus::Shipped => false, // 発送後は変更不可
OrderStatus::Cancelled => false, // キャンセル後は変更不可
};
if (!$isValid) {
throw new \InvalidArgumentException(
\Str\format(“Invalid state transition from %s to %s”, $from, $to)
);
}
}
private function executeSideEffects(OrderStatus $status, mixed $payload): void {
match ($status) {
OrderStatus::Paid => {
// ここで安全にキャストされたペイロードにアクセス可能
// 例: 非同期で決済完了メールをキューイングする等
\Cns\Log::info(“Payment confirmed, triggering webhook…”);
},
OrderStatus::Shipped => {
\Cns\Log::info(“Order shipped, notifying user…”);
},
OrderStatus::Cancelled => {
\Cns\Log::info(“Order cancelled, releasing inventory…”);
},
OrderStatus::Created => {
// 何もしない
},
}
}
}
—
4. チーフアーキテクトからの実践的アドバイス：パフォーマンスとメモリ管理の罠
この設計をプロダクション環境（HHVM）に投入するにあたり、シニアエンジニアとして知っておくべき極限の知見を共有する。
1. `mixed` ペイロードのハンドリングとボクシング（Boxing）の回避
今回のサンプルコードでは汎用性を持たせるために `mixed` を使用しているが、パフォーマンスがクリティカルなホットパス（毎秒数万件の処理が走るマイクロサービス等）においては、`mixed` によるプリミティブ型のボクシング（ヒープ割り当て）が発生し、GC（ガベージコレクション）の負荷が高まる原因になる。
対策: ジェネリクス（Generics）を活用し、状態マシンクラス自体をパラメータ化してコンパイル時型安全性を保ったままプリミティブのままメモリ上に展開せよ。
2. match式の最適化
HHVMのJITコンパイラは、`match` 式に対して非常に強力なジャンプテーブル最適化（Jump Table Optimization）を適用する。従来の `if-else` チェーンや文字列比較ベースの分岐に比べ、圧倒的な実行速度（CPUキャッシュヒット率の向上）を叩き出す。
したがって、「条件分岐は必ず `match` 式に寄せよ」。これはコードの美しさだけでなく、ハードウェアレベルの効率化に直結する。
—
5. まとめ
Hack言語の真価は、PHPの皮を被った「静的型付け言語としての極限の安全性」にある。
- `Enum Class` で状態とデータを完全に結びつけ、不正なオブジェクトの生成を断つ。
- `match` 式による網羅的チェックで、コード変更時のデグレやハンドリング漏れをコンパイラに検知させる。
この2つをマスターしたエンジニアが書くコードに、ランタイムの型エラーが入り込む余地はない。
今日のコードレビューから、「その状態遷移、型で縛っているか？」という視点をチーム全体に浸透させてほしい。圧倒的な堅牢性が、あなたのプロダクトを救うことになる。