プリミティブへの回帰を拒絶せよ：HackにおけるValue Objectによる「型レベルの防壁」構築
Hackの厳格モード（`<<__Strict>>`）は、単なるコードチェッカーではない。それは、HHVMという極限まで最適化された実行環境上で、メモリ上のデータ構造を「ドメインの論理的整合性」に直結させるための、極めて強力な静的証明ツールである。
多くの開発者は、`string` や `int` といったプリミティブ型を、単なる「データの入れ物」として扱っている。だが、システムが複雑化するにつれ、プリミティブ型は「意味の汚染」を引き起こす最大の温床となる。`UserId` も `ProductId` も、内部表現が `int` であれば、関数の引数順序を間違えた瞬間に致命的なバグがコンパイルをすり抜ける。
我々が求めるのは、型チェッカーが静的に「意味の不整合」を検知し、HHVMがそれを最適化してゼロコスト（あるいは無視できるオーバーヘッド）で実行する、洗練されたアーキテクチャだ。
—
1. 「型付きブランド化（Branded Types）」によるメモリ空間の断絶
Hackにおける Value Object の極致は、単純なクラス化ではない。`newtype` と `opaque` を駆使し、型チェッカーがコンパイル時にのみ意味を成し、実行時にはプリミティブそのものとして振る舞う設計だ。
以下の実装を見てほしい。これはドメイン境界でプリミティブの混入を物理的に遮断するパターンである。
<<__Strict>>
namespace Domain;
// opaqueキーワードにより、モジュール外からは内部構造を隠蔽する
// これにより、UserId は int とは別物として型チェックされる
newtype UserId = int;
final class UserIdentity {
public function __construct(private int $id) {}
// 内部的な生成ロジックのみがプリミティブを受け付ける
public static function fromInt(int $id): UserId {
invariant($id > 0, “IDは正の整数である必要があります”);
return (UserId)$id;
}
}
function processUser(UserId $id): void {
// ここで int を渡そうとすると、HHVMの型チェッカーが即座にエラーを吐く
// 実行時ではなく、コードを書いている瞬間に「意味的誤り」が排除される
}
このアプローチの真髄は、「型変換コストがゼロであること」だ。`newtype` はコンパイル後のHHVMバイトコード上では単なる `int` として扱われる。メモリ確保も追加のオブジェクト生成も発生しない。型システムによる「防御」を、性能犠牲なしに実装できるのは、Hackのアーキテクチャがランタイムと密接に統合されているからこそ成せる業である。
—
2. HHVMの最適化エンジンと「不変オブジェクト」の親和性
Value Object を設計する際、`readonly` プロパティや `__Immutable` 属性を組み合わせることで、HHVMのJITコンパイラは驚異的な最適化を行う。
<<__Strict>>
readonly final class Money {
public function __construct(
public int $amount,
public string $currency,
) {}
public function add(Money $other): Money {
// 不変性を保証することで、HHVMの最適化器は「この値はライフサイクル中に変更されない」
// と推論し、レジスタ割り当てを最適化する
invariant($this->currency === $other->currency, “通貨単位の不一致”);
return new Money($this->amount + $other->amount, $this->currency);
}
}
ここでのポイントは、HHVMのメモリ管理戦略にある。短命な Value Object が多量に生成される場合、HHVMはこれを「小規模オブジェクト（Small Objects）」として扱い、効率的なヒープ管理やスタック割り当ての対象とする。
不用意にミュータブル（可変）なオブジェクトを多用すれば、GC（ガベージコレクション）の負荷は増大する。しかし、このように型レベルで不変性を保証すれば、ランタイムは「コピーオンライト」の負荷を最小化し、CPUキャッシュヒット率を劇的に向上させる余地が生まれる。
—
3. シニアエンジニアが意識すべき「型レベルのドメイン駆動」
実戦では、型チェッカーを「ガードレール」ではなく「コンパイラ・プラグイン」のように扱うべきだ。
- プリミティブの排除: 可能な限り `string` や `int` を関数シグネチャから追放する。`EmailAddress` や `TransactionId` という型を定義するだけで、ビジネスロジックの誤りは「型不一致」として検出されるようになる。
- 構造的制約の強制: `shape` 型を活用し、データの形状を厳格に固定する。配列をそのまま渡すような古いPHPの悪習は、HHVMの型推論器にとって最大の敵だ。
- 徹底したエラーの局所化: `invariant` を活用し、Value Object のコンストラクタで「ドメインの境界」を定義する。ここを突破できないデータは、アプリケーションの深層部には絶対に到達しない。
結論：システムを堅牢にするのは「知恵」ではなく「型」である
多くのエンジニアは「テストコード」でバグを防ごうとする。しかし、伝説的なアーキテクチャを築く者は、「バグを発生させることが物理的に不可能であるような型空間」を設計する。
Hackの厳格モードを使いこなすということは、HHVMという最強のエンジンに対して、「ここは絶対に安全である」という証明書を型チェッカーを通じて発行し続ける作業に他ならない。
プリミティブへの依存という安易な妥協を捨てよ。あなたのコードが扱う全てのデータに「ドメイン上の意味」という重みを与えよ。それが、大規模システムにおける唯一の生存戦略である。