迷宮からの脱出：Hack型チェッカーを操り、Nullableの連鎖的崩壊を阻止する設計術
Hackの型チェッカー（HHVM Typechecker）は、単なる静的解析ツールではない。それは、君が書いたコードの「論理的整合性」を冷徹に監視する守護神だ。
多くのエンジニアが `?T` (Nullable) の扱いに苦戦し、コードの至る所で `if ($val !== null)` を繰り返す「ifの迷宮」に陥っている。だが、型システムを真に理解した者は、その伝播を制御し、安全かつ簡潔なアーキテクチャを構築する。
今日は、Nullableの伝播を抑え込み、連鎖的な型エラーを最小化する「実戦的設計術」を伝授する。
—
1. Nullableは「境界」で叩き落とせ
型エラーが連鎖するのは、`?T` を関数の奥深くまで引きずり回しているからだ。Nullableの伝播は、システムのエントリポイント（ControllerやAPIハンドラ）から数層以内で食い止めるのが鉄則である。
アンチパターン：Nullableの過剰伝播
// 悪い例：Domain LogicまでNullableが浸食している
function calculateDiscount(?User $user): ?float {
if ($user === null) return null;
return $user->getSubscription()->getDiscount(); // ここも連鎖的にNullableになるリスク
}
推奨パターン：Domain Objectへの封じ込め
Nullableな値を受け取った直後、それを「妥当なオブジェクト」または「デフォルト値」に昇華させる。これを「Type-Narrowing Gateway」と呼ぶ。
final class DiscountCalculator {
// 外部からのNullableはここで遮断し、非NullableなDomain Logicへ引き渡す
public function calculate(?User $user): float {
if ($user === null) {
return 0.0; // デフォルト戦略をここで決定する
}
return $this->executeInternal($user);
}
// ここから下は純粋な非Nullableの世界（精神衛生が保たれる）
private function executeInternal(User $user): float {
return $user->getSubscription()->getDiscount();
}
}
—
2. Maybe Monad的アプローチ：`??` と `|>` の共演
Hackには、Nullableの連鎖をエレガントに解決する強力な武器がある。`??` (Null Coalescing Operator) は単なる代入演算子ではない。型チェッカーに対する「ここからは非Nullableとして扱う」という宣言だ。
さらに、パイプライン演算子 `|>` を組み合わせることで、関数呼び出しの連鎖を記述的に処理できる。
現場で使える堅牢なコード例
<<__EntryPoint>>
function main(): void {
$rawInput = get_user_data(); // ?string が返る想定
// パイプラインでNullableを安全に変換・昇華させる
$result = $rawInput
|> ($val is null ? ‘guest’ : $val) // ここで文字列に確定
|> Str\trim($$) // 非Nullableとして処理可能
|> Str\uppercase($$);
echo $result;
}
なぜこれが美しいのか？
中間変数を定義せず、型チェッカーが推論する型を段階的に `?string` から `string` へと収束させているからだ。変数の状態が変わらないため、デバッグコストが極めて低い。
—
3. HHVMアーキテクチャの視点：なぜこれが「速い」のか
HHVMのJITコンパイラは、型が確定しているコードを好む。`?T` が残っていると、実行時に「値がnullかどうか」の分岐命令が生成され、CPUの分岐予測を汚染する可能性がある。
型チェッカーによって事前に `null` の可能性が排除されたコードは、JIT最適化の段階で「nullチェックを省いた直値アクセス」に変換される可能性が高まる。つまり、型安全を厳格に守ることは、そのままパフォーマンスの向上に直結するのだ。
—
4. プロダクションコードにおける実践の心得
最後に、チームのコードレビューで即座に使える「設計の指針」をまとめる。
1. Nullableを関数の引数にしない: 可能な限り、引数は非Nullableで設計する。Nullableが必須なら、それは「関数の責任範囲が広すぎる（S.R.P違反）」という警告である。
2. `Shapes` と `KeyedContainer` の活用: API連携でNullableが多発するなら、`Shapes::idx` を使ったデフォルト値指定を徹底せよ。
3. `expect` パターンを恐れない: どうしても `null` になってはならない箇所では、`invariant($val !== null, ‘Should not be null’);` を使え。型チェッカーはこれを見て、以降のコードで `$val` が `non-null` であると推論する。
結論
Nullableの連鎖は、君の設計が「曖昧であること」を型システムが指摘しているに過ぎない。
`if` で場当たり的に凌ぐのではなく、「どこで非Nullableに昇華させるか」という境界線を明確に設計すること。これこそが、Hackを掌握し、10年後もメンテナンス可能なシステムを作るための唯一の道だ。
コードを型に合わせるのではない。型を武器にして、コードの論理を研ぎ澄ませろ。それが伝説的なアーキテクトとしての振る舞いだ。