Hackを掌握する極限の知見：静的型システムで要塞を築く — Value Objectの極致
プロダクションコードのレビューをしていて、最も絶望的な気分になる瞬間を想像してほしい。
`string` 型の変数にメールアドレスが入っているのか、ただのランダムな文字列なのか。あるいは `int` 型の引数が「ユーザーID」なのか「秒単位のタイムアウト値」なのか。関数シグネチャを見ただけでは判別がつかず、ドキュメントや実装の奥底まで潜らなければならないコードベース。それは技術的負債の温床であり、静的型付き言語を使っていながら動的言語の悪夢を引きずっている証拠だ。
HHVMとHackの型チェッカー（hh_client）は、正しく使えば「不正な状態を表現不可能な型」をコンパイル時に強制するための最強の武器となる。
今回は、Hackの嚴格な静的モード（`<<__Strict>>`）と高度な型システムをフル活用し、ドメインの整合性を担保するValue Object（値オブジェクト）の極限設計パターンを伝授する。
—
1. なぜプリミティブ執着（Primitive Obsession）は悪なのか
多くの開発者は、IDや金額、メールアドレスを表現するために、平気で `int` や `string` といったプリミティブ型をそのまま関数の引数やクラスのプロパティに使用する。
// 【アンチパターン】プリミティブ執着の極み
// どれがどの順番で渡されるべきか、型チェッカーは何も守ってくれない
public function transferMoney(int $fromAccountId, int $toAccountId, int $amount): void {
// …
}
このコードの何が問題か？ `transferMoney($toAccountId, $fromAccountId, $amount)` と引数を逆にして渡しても、型チェッカーは文句を言わない。コンパイルは通り、本番環境で致命的なバグとして爆発する。
これを防ぐのが Value Object だ。ドメインの概念をクラス（あるいはHackの特性を活かした構造）で包み込み、「生成された時点で必ず正しい値であることが保証されている」状態を作る。
—
2. HackにおけるValue Objectの実装パターン
Hack言語では、パフォーマンスとイミュータビリティ（不変性）を極限まで高めるために、いくつかの設計アプローチが存在する。ここでは、ボイラープレートを最小限に抑えつつ、HHVMのJITコンパイラが最適化しやすい構造を持つ実装を示す。
以下のプロダクションコードを見てほしい。
<<__Strict>>
namespace Domain\Model;
/
- 厳格なメールアドレス Value Object
- 生成時にバリデーションを通過したインスタンスのみが存在を許される。
/
final class EmailAddress {
// 外部から直接書き換えられないようprivate readonlyに
private string $value;
private function __construct(string $value) {
$this->value = $value;
}
/
- ファクトリメソッドを通すことで、不正な値のインスタンス化を絶対に許さない
/
public static function fromString(string $rawEmail): this {
$trimmed = \trim($rawEmail);
// 厳格なバリデーション（簡易正規表現）
// 実際のプロダクションではより堅牢なパーサーやフィルターを通す
if (!\filter_var($trimmed, \FILTER_VALIDATE_EMAIL)) {
throw new \InvalidArgumentException(
\Str\format(‘Invalid email address format: “%s”‘, $rawEmail)
);
}
return new static(\Str\lowercase($trimmed));
}
public function toString(): string {
$this->value;
}
public function equals(EmailAddress $other): bool {
$this->value === $other->toString();
}
}
この設計の急所
1. `final` キーワード: 継承による振る舞いの改変を防ぎ、型の安全性を閉じる。
2. プライベートコンストラクタ: `new EmailAddress()` をコードベースから完全に駆逐し、必ず `fromString()` ファクトリを経由させることで、不整合なオブジェクトの存在を型レベルで排除する。
3. イミュータビリティ: 一度生成された `EmailAddress` の中身が書き換わることは絶対にない。
—
3. パフォーマンスの懸念に対するHHVMの回答
「すべてのプリミティブをオブジェクトでラップしたら、メモリ消費量が増え、GC（ガベージコレクション）の負荷が跳ね上がるのではないか？」
シニアエンジニアなら真っ先にこう懸念するはずだ。しかし、ここがHHVMの真骨頂である。
HHVMの強力なJIT（Just-In-Time）コンパイラと型推論エンジンは、逃げ切り解析（Escape Analysis）やスカラー置換（Scalar Replacement）といった最適化を行う。もしValue Objectがメソッドのスコープ内でしか使用されず、ヒープ上にallocし続ける必要がないとJITが判断した場合、オブジェクトのラッパーを剥ぎ取り、内部のプリミティブ値（`string`やチケットとしての `int`）にまでインライン展開してレジスタ上に保持する。
つまり、「美しいドメインモデルによる保守性」と「C言語並みの実行速度」をHack/HHVMでは両立できるのだ。ただし、不要なアロケーションを避けるため、コンストラクタ内での重すぎる正規表現の乱用や、ループ内での過剰なインスタンス生成には依然として注意が必要である。
—
4. 実戦投入：型安全なドメインモデルの構築
では、先ほどの `EmailAddress` を使って、実際にバグの入り込む余地のない堅牢なユーザー登録処理を書いてみよう。
<<__Strict>>
namespace Domain\Service;
use namespace Domain\Model;
use namespace HH\Lib\C;
<<__EntryPoint>>
function main(): void {
// ユースケース層を想定
$rawInput = ” ADMIN@Example.COM “;
try {
// 境界（Boundary）でプリミティブをValue Objectに昇華させる
$email = Model\EmailAddress::fromString($rawInput);
// 以降、このスコープに流れてくるEmailAddressは「100%検証済みの正しいメール」であることが保証される
registerUser($email);
} catch (\InvalidArgumentException $e) {
// エラーハンドリング
\printf(“Validation Error: %s\n”, $e->getMessage());
}
}
function registerUser(Model\EmailAddress $email): void {
// ここで string 型を間違えて渡すミスは、型チェッカーがビルド時に容赦なく叩き落とす
\printf(“Successfully registered user with normalized email: %s\n”, $email->toString());
// 出力結果: Successfully registered user with normalized email: admin@example.com
}
コードレビューの視点
もし他の開発者が「めんどくさいから」と言って `registerUser(string $email)` のようなシグネチャに戻そうとしたり、バリデーションを通していない生の一文字列をそのまま渡そうとしたら、`hh_client` は即座にエラーを吐く。
CI/CDパイプラインのビルドステップに `hh_client` を組み込んでおけば、人間がレビューし忘れたとしても、不正なコードがマージされることは物理的に不可能になる。
—
5. チーフアーキテクトからの提言
Hackの静的型システムは、単に「エラーを見つけるためのツール」ではない。それは「コードの読み手に対する強固なドキュメント」であり、「ドメインのルールを表現する言語そのもの」である。
プリミティブ型に執着するコードを書くことは、自らの手で型チェッカーの目を塞ぎ、バグを呼び込んでいるのと同じだ。
今日から、あなたのプロジェクトのドメインモデルを見直し、プリミティブな値をドメイン特有の Value Object で包み込んでほしい。そこに現れるのは、圧倒的な安心感と、変更に怯えなくてよい洗練されたコードベースだ。
型を制する者が、Hackを制する。