Hackを掌握する極限の知見：コンストラクタインジェクションと型安全な依存解決のアーキテクチャ
HHVMのランタイム内部構造、そしてHack言語が持つ静的型チェッカー（hh_client / hh_server）の挙動を熟知している我々にとって、依存性注入（DI）フレームワークの多くが無駄な実行時オーバーヘッドと、リフレクションによる型安全性の崩壊を抱えていることは自明の理だ。
動的言語の亡霊を引きずった「文字列ベースのサービスロケータ」や、実行時に`ReflectionClass`を叩くアノテーション解析は、大規模なコードベースにおいて百害あって一利なしである。ミリ秒単位のレイテンシを削り出し、JITコンパイラの最適化限界を攻める現場において、依存関係の解決はコンパイル時に完全解決されていなければならない。
今回は、Hackの厳格モード（`<<__STRICT__>>`）と高度なジェネティクス、そしてHHVMの型システムを極限まで利用した「コンパイル時・型安全コンテナ設計」の極意を授けよう。
—
1. 実行時リフレクションの排除と型チェッカーの共犯関係
一般的なPHPや一部のHack製フレームワークですら、コンストラクタの引数を実行時に解析して依存性を注入する手法をとっている。だが、これはHHVMのプロパティキャッシュやJITトレースの観点から見れば、アンチパターンでしかない。`ReflectionParameter::getType()` を呼ぶたびにランタイムコストが発生し、何より型チェッカーが「その依存関係が本当に生存しているか」を保証する網の目がすり抜ける。
Hackの型チェッカー（Typechecker）は、AST（抽象構文木）から全ファイルの依存グラフをメモリ上に構築している。我々がやるべきは、この型チェッカーに「依存関係の整合性そのものを型として検証させる」ことだ。
ゼロ・オーバーヘッド・コンテナの基本原則
1. 文字列キーの排除: サービス識別子はすべて`string`ではなく、明確な `classname
2. ファクトリの静的型付け: クロージャや匿名関数を用いる場合でも、入力と出力の型を厳格に縛る。
3. 循環依存のコンパイル時検知: 型システムの再帰制限とジェネリック制約を利用し、循環参照をビルドすらできない状態にする。
—
2. 実装：完全型安全なコンパイル時DIコンテナ
以下のコードを見てほしい。ここでは動的な文字列解決を一切行わず、`classname
<<__STRICT__>>
namespace Hack\Architecture\DI;
/
- すべての注入可能なサービスのベースインターフェース
/
interface IService {}
/
- 型安全な依存性注入コンテナ
- 実行時リフレクションを完全に排除し、クラス名とインスタンスの対応を型レベルで担保する。
/
final class TypeSafeContainer {
// 具象インスタンスを格納するマップ。キーにclassname
private dict
// サービスを生成するファクトリのレジストリ
private dict
/
- ファクトリの登録。
- 登録段階で、対象が特定のサービスクラスであることを型レベルで固定する。
/
public function bind
classname
(function(TypeSafeContainer): T) $factory,
): void {
$this->factories[$class_name] = $factory;
}
/
- 型安全なシングルトン/インスタンスの取得。
- 戻り値の型が classname
に完全に一致するため、呼び出し側でのキャストが不要。
/
public function get
$key = $class_name;
// 既にインスタンス化されていればそれを返す（ダウンキャストの安全性を保証）
if (C\contains_key($this->instances, $key)) {
// Hackの型チェッカーは厳密なアサーションを要求するため、
// ここでのAs表現はランタイムの安全弁として機能する
$instance = $this->instances[$key];
invariant(
$instance is T,
‘Type mismatch in container for %s’,
$key,
);
return $instance;
}
// ファクトリが存在しない場合はエラー（または自動推論）
invariant(
C\contains_key($this->factories, $key),
‘Unbound service dependency: %s’,
$key,
);
$factory = $this->factories[$key];
$resolved = $factory($this);
invariant(
$resolved is T,
‘Factory for %s returned an incompatible type’,
$key,
);
$this->instances[$key] = $resolved;
return $resolved;
}
}
この設計の低レイヤ優位性
- `classname
` の活用 : Hackでは `classname` は単なる文字列ではなく、静的型システムによって保護されたクラス名トークンである。これにより、タイポや存在しないクラスの指定は `hh_server` が瞬時に検知する。 - `invariant` の極限利用: HHVMは `invariant` 構文をネイティブの最適化パスで処理し、リリースビルド（`Eval.EnableHipHopSyntax=true` 等の最適化）においてオーバーヘッドを最小化する。
—
3. 実践：実際のサービス群とコンストラクタインジェクションの構築
では、上記のコンテナを実際にどのように利用し、コンストラクタインジェクションを完結させるかを示す。ここではデータベースコネクションと、それを依存するリポジトリの例をとる。
<<__STRICT__>>
namespace Hack\Architecture\Domain;
use namespace Hack\Architecture\DI;
interface IDatabaseConnection extends DI\IService {
public function query(string $sql): void;
}
final class MySqlConnection implements IDatabaseConnection {
public function __construct(private string $dsn) {}
public function query(string $sql): void {
// 実際のクエリ実行ロジック（低レイヤのPDOラッパー等）
// echo “Executing on MySQL: ” . $sql;
}
}
interface IUserRepository extends DI\IService {
public function find(int $id): void;
}
final class SqlUserRepository implements IUserRepository {
// コンストラクタインジェクション：依存関係はすべてコンパイル時に型解決される
public function __construct(private IDatabaseConnection $db) {}
public function find(int $id): void {
$this->db->query(“SELECT FROM users WHERE id = {$id}”);
}
}
配線（Wiring）のコード
コンテナへの登録部分も、クロージャの引数と戻り値が厳格に型付けられているため、誤った依存関係の注入（例：`IUserRepository` を要求する場所に全く関係ない型を渡すなど）は、エディタの保存段階（hh_serverのインクリメンタルチェック）で完全に弾かれる。
<<__STRICT__>>
namespace Hack\Architecture;
use namespace Hack\Architecture\DI;
use namespace Hack\Architecture\Domain;
function bootstrap_container(): DI\TypeSafeContainer {
$container = new DI\TypeSafeContainer();
// 1. データベース接続のバインド
$container->bind(
Domain\IDatabaseConnection::class,
(DI\TypeSafeContainer $c) ==> new Domain\MySqlConnection(‘mysql:host=localhost;dbname=prod’),
);
// 2. リポジトリのバインド（コンストラクタインジェクションの連鎖）
$container->bind(
Domain\IUserRepository::class,
(DI\TypeSafeContainer $c) ==> new Domain\SqlUserRepository(
$c->get(Domain\IDatabaseConnection::class),
),
);
return $container;
}
—
4. HHVMの内部挙動とメモリレイアウトの最適化
シニアエンジニアとして、コードがどのようにHHVM上で実行されるかを語らずしてアーキテクチャを語ることはできない。
1. JITコンパイルとメソッドインライン展開:
上記のような厳格な型付け（`<<__STRICT__>>`）が行われたコードは、HHVMのTC（Translation Cache）において、動的なメソッドディスパッチ（`method_exists` や可変関数呼び出し）が排除されやすい。型チェッカーが具象クラスやインターフェースの境界を完全に把握しているため、JITコンパイラは直接呼び出し（Direct Call）やDevirtualization（脱仮想化）の最適化を aggressively に適用できる。
2. メモリの局所性（Locality of Reference）:
`TypeSafeContainer::$instances` は `dict
3. 安全なメモリ管理:
Hackの不変性（Immutability）や所有権の概念を意識した設計を行えば、リクエストスコープごとのコンテナ破棄も確実に行われ、メモリリークの温床を断つことができる。
—
5. 結び：アーキテクチャの妥協なき防衛
動的言語出身の開発者は「型は足かせだ」と勘違いしがちだが、大規模システムや高スループットを要求されるバックエンドにおいて、厳格な静的型システムは最高にして唯一の最適化エンジンである。
コンストラクタインジェクションを文字列やマジックに頼る時代は終わった。Hackの型チェッカーを限界まで調教し、コンパイルエラーを味方につけることで初めて、私たちは「実行時エラーの恐怖から解放された、極限まで最適化されたシステム」を手に入れることができる。
コードを書け。型を縛れ。ランタイムを支配しろ。