実行時の「バリデーション地獄」を葬れ：Phantom Typesで実現する状態遷移の静的証明
現場のコードレビューで、何度も同じ「状態不整合」のバグを目にすることに飽き飽きしていないか？
`if ($order->getStatus() !== ‘APPROVED’)` といったガード節を至る所に散りばめ、単体テストで全ての状態遷移パターンを網羅しようと疲弊する――それは、型システムを「データの箱」としか見ていない証拠だ。Hackの型システムは、もっと雄弁に語れるはずだ。
今日は、HHVMの型チェッカーを武器に、ビジネスロジックをコンパイル時の静的制約へと昇華させる「Phantom Types（幽霊型）」パターンを伝授する。
—
なぜ `string` や `enum` だけでは不十分なのか
多くのエンジニアは、状態を単なる「値」として扱う。
// 危険なコードの典型
class Order {
public function __construct(private string $status) {}
public function pay(): void {
if ($this->status !== ‘APPROVED’) {
throw new Exception(“不正な状態です”);
}
// 決済処理…
}
}
このコードの問題点は、「開発者がガード節を書き忘れる」というヒューマンエラーを許容していることだ。実行時に例外を投げるのは、既に戦場に地雷を撒いているのと同じだ。我々が目指すべきは、「未承認状態の注文に対して決済メソッドを呼び出すコードが、そもそもコンパイルエラーになる」世界である。
—
Phantom Types による状態遷移の「静的保証」
Phantom Typesとは、型引数に意味を持たせ、実際には値を持たないマーカー型を付与することで、操作を制限するテクニックだ。
1. 状態を型として定義する
まずは、状態を示す空のクラスを用意する。これらはインスタンス化されない。
namespace OrderState;
interface State {}
final class Pending implements State {}
final class Approved implements State {}
final class Paid implements State {}
2. 状態を持つコンテナを設計する
`Order
final class Order
// コンストラクタは非公開にし、ファクトリメソッドで制御する
private function __construct(private int $id) {}
public static function createNew(int $id): Order
return new self($id);
}
// 承認状態へ遷移するメソッド
public function approve(): Order
return new Order($this->id);
}
}
3. 決済ロジックを「型」で縛る
ここが核心だ。`pay()` メソッドを `Order
// 拡張メソッドのように振る舞わせる、またはトレイトで分離する
extension Order
public function pay(): void {
// ここに来る時点で、状態は確実に APPROVED であることが保証されている
echo “Processing payment for order {$this->id}…\n”;
}
}
—
実務での活用：なぜこれが「最強」なのか
このコードの何が美しいか、冷静に分析しよう。
- コンパイル時の完全性: `Order
` 型のインスタンスから `.pay()` を呼び出そうとしても、HHVMの型チェッカーは容赦なく「メソッドが存在しない」と告げる。テストコードを書くまでもなく、エディタ上でバグを握りつぶせる。 - ガード節の撲滅: 決済ロジック内に `if ($status == …)` は不要だ。型システムがガードの役割を代替しているため、コードベースは驚くほど軽量化される。
- パフォーマンスのオーバーヘッドゼロ: HHVMのジェネリクスは、ランタイム時に型消去（Type Erasure）される。つまり、このチェックはコンパイル時のみの恩恵であり、実行時のメモリ消費やCPUサイクルを一切消費しない。
—
導入上の注意点と「伝説」の知見
このパターンを導入する際、一点だけ留意すべき点がある。「外部入力（DBからのフェッチやAPIレスポンス）」との境界線だ。
データベースから `status` を読み出す際、実行時の値を型にマッピングする必要がある。ここは唯一の「動的な場所」だ。
public function loadOrder(int $id): Order
$status = $this->db->fetchStatus($id);
return switch ($status) {
‘pending’ => Order::load
‘approved’ => Order::load
default => throw new InvariantException(“Unknown state”),
};
}
この「境界線」でのみバリデーションを行い、システム内部へ入った後は、型システムの保護下で安全に処理を回す。これが、大規模システムにおける「型駆動開発」の真髄だ。
最後に：エンジニアとしての矜持
Hackの厳格な型システムは、単なる制約ではない。君たちが実装しようとしている複雑なビジネスルールの「仕様書」そのものだ。
「バグが出ない」のではない。「バグを作るという概念そのものをコードから排除する」――それが、我々が目指すべきプロフェッショナルのコードだ。今日から、君のプロジェクトの `Order` クラスから、無意味な `if` 文を一つ削除してほしい。型が、君の背中を守ってくれるはずだ。