やあ。Hackの深淵へようこそ。
HHVMのJITコンパイラが吐き出す機械語の鼓動を感じながら、今日は「型」を使ってビジネスをより堅牢にする、非常に強力なテクニックについて話をしよう。
多くのエンジニアが、実行時のバリデーション（`if ($order->isPending()) { … }`）でコードを埋め尽くして疲弊している。だが、HackのStrict Modeを掌握した君なら、そんな苦労は必要ない。コンパイラを「ビジネスの門番」に変えてしまえばいいんだ。
今回は、Phantom Types（幽霊型）を用いて、状態遷移を型レベルで封じ込める極意を伝授するよ。
—
なぜ「状態遷移」を型で縛る必要があるのか？
ビジネスロジックにおいて、「未承認の注文を決済する」といったバグは致命的だよね。
多くの人は、これを実行時のif文でチェックしようとする。しかし、それは「人間が注意し続ける」という不確実な前提に立っている。
Hackの型システムは、「間違った状態のオブジェクトは、そのメソッドを呼び出すことさえできない」という制約をコンパイル時に強制できる。これがPhantom Typesの真骨頂さ。
—
Phantom Typesの仕組み：型を「タグ」として使う
Phantom Typesとは、実行時の値を持たない（あるいは無視される）型パラメータを使って、オブジェクトに「状態」というタグを貼り付ける手法のことだ。
以下のコードを見てほしい。
<<__ConsistentConstruct>>
abstract class OrderState {}
final class Pending extends OrderState {} // 未承認状態
final class Paid extends OrderState {} // 決済済み状態
// TStateはPhantom Type。実行時には何もしないが、型検査機には情報を与える。
class Order
public function __construct(private int $id) {}
public function getId(): int {
return $this->id;
}
}
// 決済処理用クラス
class PaymentProcessor {
// このメソッドは「Pending」状態の注文しか受け付けない！
public static function pay(Order
// 決済ロジック…
return new Order($order->getId());
}
}
このコードの何が凄いのか？
- コンパイル時の守護: もし誰かが決済済みの注文を誤って`pay()`に渡そうとしたら、Hackの型チェッカー（`hh_client`）は即座にエラーを吐く。
- ゼロコスト抽象化: コンパイル後のHHVM上では、`TState`の情報は綺麗に消え去る。つまり、安全性と引き換えに実行速度を犠牲にする必要がないんだ。これぞHHVMの真骨頂だよ。
—
実践：状態を遷移させる「型安全なパイプライン」
次に、注文を「作成 → 承認 → 決済」というフローで流してみよう。
// 状態を表すタグ
final class Created extends OrderState {}
final class Approved extends OrderState {}
class OrderManager {
// 作成 → 承認
public static function approve(Order
return new Order($order->getId());
}
// 承認 → 決済
public static function pay(Order
return new Order($order->getId());
}
}
function run(): void {
$order = new Order
$approvedOrder = OrderManager::approve($order);
$paidOrder = OrderManager::pay($approvedOrder);
// 試しに、承認されていない注文を直接決済しようとすると…
// $err = OrderManager::pay($order);
// ↑ ここで型エラー！「Expected Order
}
どうだい？`Order
—
初学者が陥りやすい罠と解決策
この強力な武器を使う上で、いくつか躓きやすいポイントがある。
1. 「型パラメータを忘れる」問題
`$order = new Order(1);` とだけ書くと、Hackは`Order
解決策: 常に明示的なインスタンス化を心がけよう。`new Order
2. インスタンスの複製（Immutableな思考）
Phantom Typesは「状態の遷移」を表現する際、元のオブジェクトを直接書き換えるのではなく、新しい状態のオブジェクトを返す（Immutable）設計と相性がいい。
状態を変えるたびに新しいインスタンスを生成するのはメモリの無駄に感じるかもしれないが、HHVMのメモリ管理エンジンは非常に優秀だ。型安全のために小さなオブジェクトを生成するコストは、バグ調査にかかる数時間のコストよりも遥かに安い。
—
まとめ：型は「ドキュメント」以上の存在
Hackの型システムは、単に「文字列か数値か」をチェックするツールじゃない。君たちのビジネスのルールをコード上に定着させるための「言語そのもの」なんだ。
- Phantom Typesを使えば、状態遷移のバグをゼロにできる。
- Strict Modeを貫けば、実行時のif文だらけの不格好なコードから解放される。
ここをクリアすれば、君はもうHackの初心者じゃない。HHVMのアーキテクチャが提供する最高のパフォーマンスと、型安全という最強の盾を手に入れたことになる。
次は、これをどうやって実際のプロジェクトのDTO（Data Transfer Object）に落とし込むか、一緒に考えていこうか。君のコードが、コンパイルを通るたびに研ぎ澄まされていく感覚を楽しんでほしい。
何か不明な点があれば、いつでも聞いてくれ。コードの裏側まで徹底的に解説しよう。