【実務・中級編】Hackの『Type Constants』を活用したDIコンテナの設計：具象クラスに依存しない型安全な依存解決 – Hack言語コア・静的型システムとHHVMのアーキテクチャ解析バイブル

Hackの深淵：Type Constantsを用いた「型安全なDIコンテナ」の極致

HackのStrict Modeを単なる「型チェックの強制」だと考えているなら、君はまだこの言語の本質に触れていない。

我々がHHVM上でHackを扱う最大のメリットは、ランタイムの最適化だけではない。型システムそのものを「仕様の記述言語」として使い倒し、コンパイル時（hh_client）にバグの温床を根絶できることにある。特にDIコンテナにおいて、文字列ベースのキーや`mixed`のキャストに頼る設計は、Hackの作法としては「敗北」に等しい。

今回は、`Type Constants`を活用し、コンパイル時に依存関係を静的に解決する「真に堅牢なDIコンテナ」の設計論を叩き込む。

—

1. なぜ「型定数」なのか？

一般的なDIコンテナは、`get(string $id)`のようにサービス名を文字列で指定することが多い。しかし、これは「ランタイムまで型が確定しない」という致命的な脆弱性を孕んでいる。

Hackの`type-constant`を使えば、インターフェースレベルで「このインターフェースが要求する依存オブジェクトの型」を束縛できる。これにより、コンテナから取り出した瞬間に型推論が働き、IDEの補完はもちろん、HHVMの厳格な検証をパスしたコードだけが実行されることになる。

—

2. 実装：型による依存の契約（Contract）

以下のコードを見てほしい。これが、疎結合かつ堅牢な設計のプロトタイプだ。

namespace App\DI;

依存関係を定義するインターフェース。
TService は、このインターフェースが解決すべき具象型を縛る。

/
interface IServiceFactory {
abstract const type TService;

public function create(): this::TService;
}

具体的なサービスの実装例

/
class LoggerService {
public function log(string $msg): void {
print(“Log: ” . $msg . “\n”);
}
}

ファクトリにも型定数を定義する。
これにより、どのファクトリが何を生成するかが型レベルで可視化される。

/
class LoggerServiceFactory implements IServiceFactory {
const type TService = LoggerService;

public function create(): LoggerService {
return new LoggerService();
}
}

—

3. 型安全なDIコンテナの構築

コンテナ自体に、型定数を用いたアクセス層を設ける。これにより、呼び出し側は「どのクラスが返ってくるか」を一切意識することなく、型安全にインスタンスを取得できる。

final class Container {
private dict $factories = dict[];

public function register(
classname $class,
T $factory
): void {
$this->factories[$class] = $factory;
}

型定数の恩恵：型を明示的に指定しなくても、
ファクトリの型定数から戻り値の型が自動的に決定される。

/
public function get(classname $class): T::TService {
return $this->factories[$class]->create();
}
}

// 利用例：
<<__EntryPoint>>
function main(): void {
$container = new Container();
$container->register(LoggerServiceFactory::class, new LoggerServiceFactory());

// 型推論により、$logger は LoggerService であると確定する
$logger = $container->get(LoggerServiceFactory::class);
$logger->log(“DI is now type-safe.”);
}

—

4. アーキテクチャの要点：パフォーマンスと保守性

この設計の強みは、単なる「綺麗さ」ではない。

HHVMのJIT最適化: `type-constant`はコンパイル時に解決されるため、ランタイムのオーバーヘッドは最小限だ。`mixed`型による動的なディスパッチを排除することで、HHVMのType Profilerが効率的に機能する。
リファクタリング耐性: サービスの実装を変えても、`type-constant`の定義を書き換えれば、依存している全ての箇所で即座にコンパイルエラーが発生する。修正漏れという「人為的ミス」が、コードを書く瞬間に可視化される。
非同期API連携への応用: 非同期処理（`Awaitable`）と組み合わせる際、`TService`を`Awaitable`にすることで、非同期処理の戻り値まで含めた「型保証された依存関係」を構築可能だ。

—

最後に：コードは「契約」である

DIコンテナは単なる箱ではない。それはアプリケーションの構成要素が互いをどう呼び合うかという「契約」の集積所だ。

HackのStrict Modeで開発するということは、コンパイラをあなたの最強のペアプログラミング相手に仕立て上げることだ。`type-constant`を駆使し、実行時にエラーが起きる余地を一切排除したコードを書く。それこそが、世界最高峰のエンジニアが歩むべき道である。

次は君の番だ。既存のレガシーなDIコンテナを捨て、この型安全な設計で書き換えてみろ。コンパイルが通った瞬間、君はシステムという名の巨大なパズルが、型という強力な接着剤で強固に組み上がったことを実感するはずだ。