Hackの型システムで「バグ」を絶滅させる：Phantom Typesによる状態遷移の静的保証
Hackの真髄は、単なるPHPの「型付き版」であることではない。その本質は、HHVMが提供する強力な型チェッカーを、単なるデータチェックツールではなく、「ビジネスルールの検証エンジン」として使い倒すことにある。
多くのエンジニアは、実行時の`if`文や例外処理で「不正な状態」をガードしようとする。だが、それは甘い。実行時にエラーを見つけている時点で、設計は既に敗北している。
今回は、Hackの「Phantom Types（幽霊型）」を駆使し、コンパイル時に状態遷移を確定させる、堅牢かつ美しい設計パターンを伝授する。
—
1. なぜ「動的チェック」は負けなのか
例えば、ECサイトの「注文処理」を考えてほしい。
`Pending` -> `Paid` -> `Shipped` という遷移ルールがあるとする。
// 悪い例：実行時にチェックする
class Order {
public string $status;
public function ship(): void {
if ($this->status !== ‘Paid’) {
throw new Exception(‘未払いの注文は発送できません’);
}
// 発送処理…
}
}
このコードの何が悪いか？ 状態が増えるたびに`if`の分岐が複雑化し、テストコードで全ての遷移パターンを網羅しなければならない。さらに、「開発者がメソッドを呼ぶ順序を間違える」というヒューマンエラーをコンパイル時に防げない。
型システムは、ドキュメント以上に雄弁であるべきだ。
—
2. Phantom Typesによる状態の「型化」
Phantom Typeとは、実際の実行時には値を持たない（あるいは意味をなさない）型パラメータを利用して、コンパイル時に型の整合性を強制するテクニックだ。
実装パターン：状態遷移の静的保証
<<__ConsistentConstruct>>
abstract class OrderStatus {}
final class Pending extends OrderStatus {}
final class Paid extends OrderStatus {}
final class Shipped extends OrderStatus {}
/
- TStatus を型パラメータとして持つことで、
- インスタンスがどの状態にあるかを型レベルで固定する
/
final class Order
public function __construct(private int $id) {}
public static function create(): Order
return new Order(1);
}
}
// 拡張メソッドのように振る舞う責務の分離
final class OrderProcessor {
// Pendingの状態のみ、Payメソッドを許可する
public static function pay(Order
return new Order($order->getId()); // 状態がPaidに遷移
}
// Paidの状態のみ、Shipメソッドを許可する
public static function ship(Order
// 発送処理
}
}
この設計の衝撃的なメリット
1. コンパイルエラーが仕様書になる
`OrderProcessor::ship($order)` に `Order
2. 実行時コストゼロ
この型チェックはコンパイル時に解決される。実行時のHHVMのバイトコードには、この型情報は一切残らない。つまり、パフォーマンスを犠牲にせずに「安全」を買い叩ける。
3. 読みやすさ
シグネチャを見るだけで、その関数が「どの状態のオブジェクトを期待しているか」が一目瞭然になる。
—
3. 実務への応用：非同期API連携の堅牢化
非同期処理やAPI連携では、「通信済みか否か」の状態管理がバグの温床となる。
final class Unsent {}
final class Sent {}
final class ApiRequest
public function __construct(private string $payload) {}
}
function sendRequest(ApiRequest
// 通信処理
return new ApiRequest($req->payload);
}
// 利用側
$req = new ApiRequest(‘data’);
$sent = sendRequest($req); // OK
// sendRequest($sent); // コンパイルエラー！二重送信を型で物理的に防ぐ
このように、「操作の順序」を型システムに組み込むことで、単体テストの工数を劇的に削減しつつ、コードの品質を底上げできる。
—
4. チーフアーキテクトからの助言
Phantom Typesを導入する際、以下の点に注意せよ。
- 過剰な抽象化を避ける: あまりに細かい状態遷移を型に落とし込みすぎると、コードが複雑化しすぎて保守性が下がる。ビジネスにおいて「本当に防ぎたい致命的なバグ」にのみ適用せよ。
- HHVMの `newtype` との併用: モジュール外に内部状態を隠蔽したい場合は、Hackの `newtype` と組み合わせることで、さらに強固なカプセル化が可能だ。
型システムを「制約」と捉えるな。「設計の強力な味方」と捉えろ。
Hackを掌握するとは、HHVMの型チェッカーを自身の設計思想の延長線上に置くことだ。
さあ、型定義を書き換えろ。バグのない世界は、そこから始まる。