【テクニカル・上級編】Hackにおける『Value Object』の設計パターン：型システムでドメインを表現する – Hack言語コア・静的型システムとHHVMのアーキテクチャ解析バイブル

Hackを掌握する極限の知見：Value Objectパターンと静的型システムの限界突破

HHVM（HipHop Virtual Machine）のアーキテクチャ、そして厳格な静的型システム（Strict Mode）の深淵へようこそ。私は長年、この言語のランタイムとコンパイラパイプラインの限界を押し広げてきた。

世間では、Hackは「PHPの高速な方言」程度に認識されているかもしれない。しかし、それは致命的な誤解だ。HHVMのJITコンパイラと型チェッカー（hh_client / hh_server）は、適切に調律されれば、C++やRustに匹敵するドメインモデルの厳密性を、Webスケールのスループットで実現する。

今回は、プリミティブ型への依存という悪習を断ち切り、Hackの静的型システムを極限まで活用してドメインを表現する「Value Object（値オブジェクト）」の設計パターンについて、ランタイムのメモリ表現や型チェッカーの挙動に踏み込んで解説する。

—

1. プリミティブ・オセロシスの罠と型システムの防壁

大規模なコードベースにおいて、次のようなコードを見たことはないだろうか？

// 典型的なアンチパターン（Primitive Obsession）
function transfer_funds(string $from_account, string $to_account, float $amount): void {
// …
}

このコードの何が問題か。型チェッカーの視点から見れば、`$from_account` も `$to_account` も `$amount` も、単なる `string` と `float` でしかない。悪意ある入力、あるいはヒューマンエラーによって、金額にアカウントIDが渡されても、型チェッカーは静的にこれを検知できない。PHP由来の動的血統を引き継ぐコードベースでは、これがサイレントバグや深刻な脆弱性の温床となる。

Hackの `strict` モード（`<>`）において、我々は型を単なる「データの入れ物」ではなく、「ドメインの不変条件（Invariants）を保証する数学的証明」として扱わなければならない。

—

2. HackにおけるValue Objectの実装アーキテクチャ

Value Objectの本質は以下の3つに集約される：
1. 不変性（Immutability）：生成後に内部状態を変えてはならない。
2. 等価性（Equality）：識別子ではなく、保持する値によって同一性が決まる。
3. 自己検証（Self-validation）：生成された時点で、不正な状態が存在し得ない。

Hackでこれを最も効率的かつ、HHVMのメモリ最適化の恩恵を受けられる形で実装するコードを見てみよう。

namespace Domain\Finance;

金額を表すValue Object
浮動小数点の丸め誤差を排除するため、内部表現として整数（最小通貨単位：セント等）を保持する。

/
readonly class Money {
private int $cents;

public function __construct(int $cents) {
if ($cents < 0) { throw new \InvalidArgumentException("Money cannot be negative."); } $this->cents = $cents;
}

ファクトリメソッド：人間が読みやすいドル表記から生成する

/
public static function fromFloat(float $amount): this {
// 浮動小数点の厳密性に関する懸念をここでラップする
$cents = (int)\round($amount 100);
return new self($cents);
}

public function getCents(): int {
return $this->cents;
}

public function add(Money $other): this {
// 新しいインスタンスを返却し、不変性を維持する
return new self($this->cents + $other->cents);
}

public function equals(Money $other): bool {
return $this->cents === $other->cents;
}
}

この設計がHHVM上で持つ優位性

1. `readonly class` とメモリレイアウト:
Hackの `readonly` 修飾子が付与されたプロパティは、HHVMのオブジェクトヘッダ内において最適化の対象となる。JITコンパイラ（Region JIT）は、このプロパティが不変であるという前提（Immutable Assumption）の元で、メモリーロードのインライン化や、不要なバリア処理の省略といった高度な最適化（Scalar Replacement of Aggregatesなど）を適用できる。
2. ゼロコスト抽象化の幻想を捨てる、しかし実用的なコスト:
C++の `constexpr` や Rust のゼロコスト抽象化とは異なり、HHVM上ではオブジェクトのインスタンス化に伴うオーバーヘッド（Object Header + Property Table）が存在する。しかし、後述するShapeやType Aliasとの組み合わせ、そしてHHVMの高速なアロケータ（ jemalloc ベースのカスタムアロケータ）により、このオーバヘッドは実用上完全に無視できるレベルに抑え込まれる。

—

3. 型エイリアス（Type Aliases）との使い分け：いつClassを切り、いつopaqueを使うべきか

パフォーマンスの極限を追求する場合、すべてのValue Objectをクラスとしてインスタンス化することが最適解とは限らない。HHVMのメモリフットプリントを最小限に抑えつつ、厳格な型安全性を担保したい場合、`newtype`（Opaque Type Aliases）が最強の武器となる。

namespace Domain\Security;

// モジュール境界の外側からは単なる string だが、モジュール内では厳格に区別される
newtype AccountId = string;

class AccountRepository {
public static function find(AccountId $id): ?Account {
// $id は string として扱えるが、外部から生の string を渡すことはコンパイルエラーになる
// …
}
}

アーキテクチャ上の選択基準

シニアエンジニアとして、メモリ帯域やGC（ガベージコレクション）のプレッシャーを極限まで下げたいホットパス（秒間数十万リクエストを処理するルーティング層など）では `newtype` を採用し、ビジネスロジックのドメインモデル層ではリッチな振る舞いを持つ `readonly class` を採用するのが、HHVMアーキテクチャを最も効率的に駆動させる布陣となる。

—

4. 型チェッカーの限界を突破する：Generics と Phantom Types

さらに高度な型安全性を求めるならば、Phantom Types（幽霊型）の導入を検討せよ。これは、実行時には何のデータも持たない型パラメータを利用して、コンパイル時に状態遷移を完全に強制するテクニックだ。

例えば、「未検証のユーザー入力」と「サニタイズ済みの安全な文字列」を型レベルで厳密に区別する例を見てみよう。

// 状態を表すマーカークラス
class Unvalidated {}
class Sanitized {}

幽霊型 $T を持つ文字列ラッパー

/
readonly class SecureString {
private string $value;

private function __construct(string $value) {
$this->value = $value;
}

public static function untrusted(string $raw): SecureString {
return new self($raw);
}

サニタイズ処理を経てのみ、SecureString へ移行できる

/
public function sanitize(): SecureString {
$clean = \htmlspecialchars($this->value, \ENT_QUOTES, ‘UTF-8’);
return new SecureString($clean);
}

public function toStringForDatabase(): string
where T = Sanitized { // Contextual constraints (Hackの強力な機能)
return $this->value;
}
}

// — 使用例 —
function process_request(string $userInput): void {
$rawInput = SecureString::untrusted($userInput);

// コンパイルエラー！ Unvalidated 状態のままではデータベースに保存できない
// $db->save($rawInput->toStringForDatabase());

$safeInput = $rawInput->sanitize();

// コンパイル成功！ Sanitized 状態なので型チェッカーが許可する
$db->save($safeInput->toStringForDatabase());
}

このコードにおける `where T = Sanitized` というContextual Constraints（文脈制約）に注目してほしい。これはHackの静得型システムが誇る最も洗練された機能の一つであり、特定の型パラメータが特定の条件を満たす場合のみメソッドの存在を許容する。

実行時には余分なオーバーヘッドを一切生まないこのコードは、HHVMのJITによって完全にプリミティブな文字列操作へと最適化される一方で、開発者の誤謬（うっかり未サニタイズのままSQLやHTML出力に渡すミス）をコンパイルタイムに100%封じ込める。

—

5. 結言：型システムとは、エンジニアの意志のコード化である

動的言語の柔軟性は、時として保守性の崩壊とセキュリティインシデントという代償を伴う。しかし、Hack言語とHHVMが提供する厳格な静的型システムを正しく理解し、Value ObjectやOpaque Types、そしてコンテキスト制約を駆使すれば、「間違ったコードが書けない」理想郷を構築できる。

ランタイムの挙動を脳内でトレースし、コンパイラの最適化パスと対話しながらコードを書く。それこそが、真のHackプロフェッショナルの姿だ。

プリミティブへの依存を捨てよ。型でドメインを語れ。コードベースの静寂と堅牢さは、そこからしか始まらない。