HackのEnum Classで実現する「壊れない」状態遷移：定数管理からの脱却
Hackの型システムを「単なるPHPの強化版」だと思っているなら、今すぐその認識を捨てろ。我々が開発した`Enum Class`は、単なる値の羅列ではない。これは型レベルで安全性を保証するための、最も強力なステートマシン構築ツールだ。
多くのエンジニアが陥る罠は、状態管理を`string`や`int`の定数で行い、`switch`文の`default`節で「ありえないはずのパス」を処理しようとすることだ。それはバグの温床であり、型チェッカーへの冒涜だ。
今日は、Enum Classを使って、非同期API連携における「状態遷移の不整合」をコンパイル時に抹殺する設計パターンを伝授する。
—
1. なぜEnum Classなのか：コンパイル時の強制力
従来の`enum`は「値」の集合体だったが、`enum class`は「型」そのものを定義する。これにより、特定の状態に関連付けられたメソッドや、コンテキストに応じたデータ保持が可能になる。
以下のコードを見てほしい。非同期決済システムの「状態」を管理する例だ。
<
// 状態に応じたデータ型を定義
enum class PaymentState : mixed {
// 状態ごとの型を定義
Pending(void);
Processing(string); // トランザクションIDを持つ
Completed(float); // 決済額を持つ
Failed(string); // エラーメッセージを持つ
}
// 状態遷移を強制するハンドラー
final class PaymentStateMachine {
private PaymentState::T _state = PaymentState::Pending;
public function transition(PaymentState::T $next): void {
// ここで遷移の妥当性をチェックできる
// 例: FailedからCompletedへの遷移を禁止するロジックなど
$this->_state = $next;
}
public function getState(): PaymentState::T {
return $this->_state;
}
}
この設計の肝は、`Processing`状態の時に必ず`transactionId`が存在することを型レベルで保証できる点にある。`if`文で型を絞り込む必要はない。`HHVM`の型チェッカーが、不正な状態アクセスをビルド時に弾くからだ。
—
2. 実務で活きる「型安全なステートマシン」の実装
複雑な非同期フローでは、「どの状態からどの状態へ遷移できるか」を厳格に制御しなければならない。これを`Enum Class`のメソッドでカプセル化する。
<
enum class OrderStatus : mixed {
Created(void);
Shipped(string); // 追跡番号
Delivered(void);
Cancelled(string); // キャンセル理由
}
final class OrderManager {
private OrderStatus::T $status = OrderStatus::Created;
public function ship(string $trackingNumber): void {
// 型チェッカーは $this->status が Created であることを要求する
if ($this->status is OrderStatus::Created) {
$this->status = OrderStatus::Shipped($trackingNumber);
} else {
throw new InvalidStateException(“出荷済み、またはキャンセル済みです”);
}
}
public function getTrackingNumber(): ?string {
$s = $this->status;
// パターンマッチングで型を安全に抽出
return ($s is OrderStatus::Shipped) ? $s->value : null;
}
}
なぜこの設計が美しいのか
1. ランタイムの不整合を排除: `Shipped`状態以外で追跡番号を取り出そうとすれば、静的解析が即座に警告を出す。
2. メモリ効率: `HHVM`の内部実装において、`Enum Class`は非常に軽量なハッシュテーブルとして最適化される。巨大なオブジェクトを生成するより遥かに高速だ。
—
3. パフォーマンスと運用の注意点：チーフアーキテクトからの助言
`Enum Class`は強力だが、魔法ではない。以下の点に注意せよ。
- 無闇な複雑化を避ける: 状態数が100を超えるようなステートマシンは、`Enum Class`で解決すべきではない。それはドメイン設計自体が肥大化している証拠だ。その場合は、状態を分割して小さなステートマシンを組み合わせるべきだ。
- シリアライズの考慮: 非同期処理でAPIを跨ぐ場合、`Enum Class`をJSONとしてシリアライズする仕組みが必要になる。`enum_class_label`を使って、シリアライズ用のマッピング関数を共通化しておくことを推奨する。
- HHVM最適化: `enum class`は`final`なクラスとして扱うのが鉄則だ。継承による拡張は型推論の複雑度を上げ、HHVMのJITコンパイラの最適化パスを阻害する可能性がある。
—
結論：型は「ドキュメント」ではなく「契約」である
コードレビューで「この状態はnullかもしれないからifを入れて」というやり取りを繰り返すのは、もう終わりにしよう。`Enum Class`を使い、取りうる状態を型システムに明示せよ。
型チェッカーがエラーを吐くとき、それはバグを防いだという勲章だ。`Enum Class`をマスターし、堅牢で、かつ変更に強いシステムを構築せよ。我々Hackのコミュニティにおいて、型を妥協することは、エンジニアとしてのプライドを妥協することと同義なのだから。
次回のコードレビューで、お前のコードがこの設計指針を体現していることを期待している。