型の「幽霊」を追うな：Type Constantsによる疎結合DIの極致
HackのStrict Modeで開発している諸君、君たちはまだ「具象クラス」に依存したDIコンテナで疲弊しているのか？
`Container::get(Database::class)` のようにクラス名を引数に取るコードは、一見クリーンに見えて、実は型システムに対する敗北宣言だ。インターフェースと実装が密結合になり、依存グラフはスパゲッティ化する。HHVMのJITコンパイラがどれほど最適化を重ねようとも、設計の「型」が緩んでいれば、システムは実行時に崩壊する。
今日は、Type Constants（型定数）を駆使し、DIコンテナの抽象度を限界まで引き上げるアーキテクチャを伝授する。これは単なる小手先のテクニックではない。君のコードから「キャスト」という名の癌を根絶し、コンパイル時に全ての依存関係を静的に解決するための、最高峰の設計論だ。
—
なぜ `class-string` では不十分なのか
多くのDI実装で見かける `T as MyInterface` のようなキャストは、型チェッカーに対する「私は責任を持てない」という告白に過ぎない。
真に堅牢なDIは、「どのインターフェースがどの型を必要としているか」をクラス自体が型定義として保持する必要がある。ここで登場するのが `type` キーワードだ。
実装パターン：型定数によるDIの抽象化
以下のコードを見てほしい。データ取得処理を抽象化し、DIコンテナが具象クラスを知ることなく、型安全にインスタンスを生成する設計だ。
<<__ConsistentConstruct>>
interface IDataProvider {
// ここが核心。具象クラスはこの型定数を定義しなければならない
abstract const type TResult;
public function fetch(int $id): this::TResult;
}
class UserProvider implements IDataProvider {
// 具体的な返り値の型をここに閉じ込める
const type TResult = User;
public function fetch(int $id): User {
return new User($id, “Hack Architect”);
}
}
// DIコンテナ側での利用例
class ServiceContainer {
public function resolve
// インスタンス化のロジック（実際はReflectionやFactoryを使用）
return new $class();
}
}
// 呼び出し側
$provider = (new ServiceContainer())->resolve(UserProvider::class);
// 型チェッカーは $result が User 型であることを静的に追跡する
$result = $provider->fetch(1);
—
この設計がもたらす「静的解析の特権」
このコードの美しさは、`fetch()` メソッドの戻り値が `this::TResult` と定義されている点にある。
1. コンパイラによる自動追跡: `UserProvider` を利用するコードでは、`TResult` が `User` であるとチェッカーが推論する。もし将来 `UserProvider` が返す型を変更しても、利用側のコードで型不整合が起きれば、HHVMの型チェッカーが即座にCIを止めてくれる。
2. 実行時のオーバーヘッドゼロ: 型定数はコンパイル時に解決される。実行時に型チェックのための動的な `instanceof` を繰り返す必要はない。HHVMのJIT最適化エンジンは、この構造を「静的な型解決」として認識し、インライン化の効率を極限まで高める。
3. DIコンテナの責務分離: コンテナは「どのクラスを生成するか」というメタデータのみを管理し、具体的なデータ構造（TResult）の詳細は各クラスに委譲される。これが「真の疎結合」だ。
—
注意点：パフォーマンスと再帰的定義の罠
もちろん、強力な武器にはリスクが伴う。以下の2点には注意せよ。
- 循環依存の回避: 型定数内でクラスの複雑な型を再帰的に参照すると、HHVMの型推論器が「型解像度のタイムアウト」を起こす可能性がある。インターフェース定義には、できる限りプリミティブな型か、またはシリアライズ可能なDTOを配置するよう設計せよ。
- 型消去（Type Erasure）の壁: Hackは実行時に型情報を完全に保持するわけではない。`TResult` を使った実行時の型判定が必要な場合は、`is` 演算子と `shape` の組み合わせを検討せよ。だが、原則として「実行時に型を判定しなければならない設計」自体が、設計の脆弱性であることを自覚すべきだ。
—
結論：型は「守るもの」ではなく「設計するもの」
中級者は型チェッカーに怒られることに怯えるが、上級者は型チェッカーを「最強の自動テスト」として使い倒す。
Type Constantsを用いたDI設計は、君のアプリケーションを「動けばいいコード」から「壊れることが不可能なシステム」へと進化させる。コードレビューの際、`mixed` や `dynamic` が散見されるようなら、即座にこのパターンを適用してリファクタリングせよ。
型は君を縛る鎖ではない。堅牢なアーキテクチャを構築するための、最も信頼できる「設計図」なのだ。
さあ、コードを開け。君の定義したインターフェースに、魂（型）を吹き込む時間だ。