【上級者向け】Phantom Typesによるビジネスロジックの型安全化：コンパイル時に状態遷移を保証する
テックリードの私だ。コードレビューで「なぜこのメソッドは、未決済の注文に対して出荷処理を呼べてしまうのか？」「バリデーションを通したはずなのに、なぜNULLチェックが散在しているのか？」といった議論に疲弊していないか？
動的言語上がりのエンジニアは「テストを書けば防げる」と言うが、大規模なWebアプリケーションにおいて、複雑な状態遷移（ステートマシン）のバグをテストだけで網羅するのは悪夢だ。ランタイムの例外やバグは、プロダクション環境で顧客がボタンを連打した瞬間に牙を向く。
HHVMとHack言語の厳格な静的型システム（Strict Mode）を極めた者であれば、「不正な状態のオブジェクトをインスタンス化すること自体を型チェッカーに禁止させる」というアプローチをとる。
今回は、Hackの強力な型システムを利用したPhantom Types（ファントム型）による状態遷移のコンパイル時強制パターンを伝授する。
—
1. なぜ「フラグ管理」と「動的チェック」は破綻するのか？
多くの現場で見かけるアンチパターンは、以下のようなドメインモデルだ。
// 【アンチパターン】単一のクラスでフラグによって振る舞いを変える設計
<<__EnforceGlobalEventListeners>>
class Order {
private string $status = ‘CREATED’;
public function pay(): void {
if ($this->status !== ‘CREATED’) {
throw new InvalidStateException(“Invalid state for payment”);
}
$this->status = ‘PAID’;
}
public function ship(): void {
if ($this->status !== ‘PAID’) {
throw new InvalidStateException(“Invalid state for shipping”);
}
$this->status = ‘SHIPPED’;
}
}
この設計の何がクソなのか？
1. 認知負荷の増大: どのメソッドがどのステートで安全に呼び出せるか、開発者は頭の中でステートマシンをシミュレートしなければならない。
2. ランタイムコスト: すべてのメソッド呼び出しの先頭でガード節（`if` 文）の評価と例外のコストが発生する。
3. 型情報の欠落: `Order` 型を受け取る関数は、それが「作成されたばかり」なのか「支払い済み」なのかを型レベルで知ることができない。
HHVMのJITコンパイラは非常に優秀だが、無駄な条件分岐や例外スローのパスは最適化の足を引っ張る。何より、「コンパイル時に防げるバグを、わざわざ動的チェックに頼るな」というのが私の信条だ。
—
2. Phantom Types（ファントム型）とは何か？
Phantom Type（幽霊型）とは、データ構造自体には保持されないが、型システムの上だけで「そのデータがどのような文脈・状態にあるか」を追跡するためのジェネリック型引数のことだ。
Hackの強力なジェネリクスと `<<__Strict>>` を組み合わせることで、「状態ごとに完全に異なるクラス（型）」をゼロコストの抽象化として実現できる。
早速、実務でそのまま使えるプロダクションコードを見てみよう。
—
3. 実装例：注文のライフサイクルをコンパイル時に強制する
以下のコードは、`Created` $\to$ `Paid` $\to$ `Shipped` という厳格な状態遷移を、Phantom Typesを用いてHackの型チェッカーに完全に強制させる実装だ。
<
namespace Domain\Order;
/ —————————————————————–
- 1. 状態を表すマーカーインターフェイス（Phantom Types）
- —————————————————————– /
interface IOrderState {}
class Created implements IOrderState {}
class Paid implements IOrderState {}
class Shipped implements IOrderState {}
/ —————————————————————–
- 2. 状態を型パラメータ $TState に閉じ込めたドメインモデル
- 登録された型引数に応じて、呼び出せるメソッドが完全に制限される
- —————————————————————– /
class Order
private int $id;
private int $amount;
// コンストラクタはプライベート。ファクトリーメソッド経由でのみ生成を許可する
private function __construct(int $id, int $amount) {
$this->id = $id;
$this->amount = $amount;
}
/
- 新規注文を作成する（エントリポイント）
/
public static function create(int $id, int $amount): Order
return new Order
}
/
- 支払い処理：Created 状態の Order でのみ呼び出し可能
- 戻り値として、新しい状態（Paid）を持つ Order インスタンスを返す
/
public function pay(string $paymentGatewayToken): Order
// ここで実際の決済API連携などのビジネスロジックを実行
// 型が Order
\Log::info(“Processing payment for order {$this->id}”);
// 新しい状態の型にキャストして返却（イミュータブル設計）
return new Order
}
/
- 出荷処理：Paid 状態の Order でのみ呼び出し可能
/
public function ship(string $trackingNumber): Order
\Log::info(“Shipping order {$this->id} with tracking {$trackingNumber}”);
return new Order
}
public function getId(): int {
return $this->id;
}
public function getAmount(): int {
return $this->amount;
}
}
/ —————————————————————–
- 4. アプリケーション層（ユースケース）での利用例
- —————————————————————– /
final class OrderService {
public function checkoutProcess(int $orderId, int $amount, string $token): Order
// 1. 注文作成 (Order
$order = Order::create($orderId, $amount);
// 2. 決済実行 (Order
$paidOrder = $order->pay($token);
// 【コンパイルエラーになる例】 HHVMの型チェッカー（`hh_client`）は、静的解析の段階でこれらの型関係をすべて解決する。 開発者がどれほど疲弊していろうとも、リファクタリングでコードを書き間違えようとも、型チェッカーが通らないコードはデプロイできない。 変数の型が `Order — このパターンを実際のプロダクションに導入する際、以下の点に注意してほしい。 1. イミュータブル（不変）を貫くこと public function loadOrderFromDb(int $id): ?IOrderStateContainer { 境界部分で一度型を正しく付与してしまえば、その後のドメインロジック内では型の安全性が完全に保証される。 — Hack言語の厳格な静的型システムは、単に「型エラーを防ぐため」のものではない。「ビジネスロジックのルール自体を型言語で記述し、言語処理系に強制させる」ための最強の武器だ。 動的言語のノリを引きずったコードレビュー文化は今日で終わりにしよう。Phantom Typesを使いこなし、コンパイルエラーを味方につけた、真に堅牢なプロダクションコードを構築してほしい。
// 支払い前の $order に対して直接 ship() を呼ぼうとすると、
// Hackの型チェッカーが “Method ship() not found on Order
// $order->ship(“TRK-123”); // <-- hh_client がビルドを弾く
return $paidOrder;
}
}
---
4. この設計がもたらす圧倒的なメリット
① ランタイムのオーバーヘッドが「ゼロ」
実行時（バイトコード実行時）には、Phantom Typeの実体は単なるオブジェクトであり、余計なポリモーフィズムのディスパッチや、状態検証のための条件分岐（`if` 文）は一切生成されない。これは極限のパフォーマンスを要求されるWebAPIにおいて強烈なアドバンテージとなる。② 不正な遷移の完全な根絶
「決済していない注文の出荷」や「二重支払い」といった致命的なビジネスロジックのバグは、開発者のローカル環境やCI/CDパイプラインのビルドステップで100%遮断される。③ IDEの補完機能の劇的向上
5. テックリードからの実務上のアドバイス
状態が変化するたびに新しい `Order` インスタンスを返す（あるいは内部データを安全にコピーして型を付け替える）イミュータブルな設計にすること。ミュータブルなオブジェクトでPhantom Typeをやろうとすると、型と実態が乖離して破滅する。
2. データベース永続化層（ORマッパー）との境界
DBからデータをロードする際は、データベース上のステータス（カラム値）を読み取り、対応するファクトリーメソッドを使って適切なPhantom Typeに「キャスト（昇格）」する必要がある。
$row = $this->db->fetchRow($id);
switch ($row[‘status’]) {
case ‘CREATED’: return Order::createFromPersistence
case ‘PAID’: return Order::createFromPersistence
// …
}
}結び