Hackを極めし者へ：Type Constantsがもたらす『真に型安全なDI』の極限領域
コードレビューでよく見かける光景がある。汎用的なDIコンテナを構築しようとした結果、インターフェースのメソッドシグネチャが `mixed` や `Traversable
「うちはStrict Modeだから安全です」——本当にそうか？
型チェッカーの目を欺く `mixed` の乱用は、静的解析の放棄に他ならない。Hack言語の真価は、緩い型付けの妥協を一切許さない『Strict Mode』と、HHVMのJITコンパイラが最適化しやすい静的構造の融合にある。
今回は、Hackの強力な武器である Type Constants（型定数） を用い、インターフェースレベルで型を完全に抽象化しつつ、実行時コストをゼロにして型安全な依存注入（DI）を実現する設計パターンを伝授する。
—
なぜ従来のDIは破綻するのか？
一般的なPHPや、あるいは不十分なHackのジェネリクス利用において、インターフェースが具象の型を知りすぎたり、逆に知らなさすぎたりするジレンマに直面する。
例えば、あるデータストアとそれに対応するシリアライザを注入したい場合を考えてみよう。
// 悪夢のアンチパターン：mixedの温床
interface IRepository {
public function save(mixed $entity): void;
public function find(int id): mixed;
}
この設計では、呼び出し側は常にダウンキャストが必要になり、型チェッカーは何も守ってくれない。では、ジェネリクス（Generics）を使えば解決するだろうか？
// ジェネリクスを用いたアプローチ（これでもまだ不十分な場合がある）
interface IRepository
public function save(T $entity): void;
public function find(int id): T;
}
単一のエンティティを扱う分には機能するが、「リポジトリ」「シリアライザ」「バリデータ」「ロガー」といった複数の依存コンポーネント間で、特定のドメインモデル型をコンパイル時に厳密に一致させたい場合、ジェネリクスのボイラープレート地獄に陥るか、型制約（Type Constraints）の複雑化によりコードが破綻する。
ここで登場するのが Type Constants（型定数） だ。
—
Type Constantsによる抽象化：インターフェースの「型パッチング」
Type Constantsとは、クラスやインターフェースの内部に `const type` として型を定義し、具象クラスでそれを具体化（Concrete）する機能だ。
これを利用すると、「このコンポーネント群は、どのドメインモデルを対象とするか」をインターフェースの契約（Contract）として静的に固定できる。
プロダクションコード例：型安全なDIコンポーネント
以下のコードを見てほしい。データ永続化層とシリアライザ層が、Type Constantsを通じて完全に型安全に結びついている。
<
namespace App\DataFlow;
/
- ドメインモデルのベースインターフェース
/
interface IEntity {
public function getId(): int;
}
/
- 1. 型定数を保持する基底コントラクト
- このインターフェースを実装する群は、必ず同一の TEntity を共有しなければならない。
/
interface IHasEntityContext {
abstract const type TEntity as IEntity;
}
/
- 2. リポジトリの抽象
/
interface IRepository extends IHasEntityContext {
public function findById(int $id): ?this::TEntity;
public function persist(this::TEntity $entity): void;
}
/
- 3. シリアライザの抽象
/
interface ISerializer extends IHasEntityContext {
public function serialize(this::TEntity $entity): string;
public function unserialize(string $raw): this::TEntity;
}
/
- 4. 具象実装：Userドメインに関するコンポーネント群
/
class User implements IEntity {
public function __construct(
public int $id,
public string $email,
) {}
public function getId(): int {
return $this.$id;
}
}
class UserRepository implements IRepository {
// ここで抽象型を具象型（User）にバインドする
const type TEntity = User;
public function findById(int $id): ?User {
// データベースから取得するロジック（省略）
return new User($id, “architect@hhvm.com”);
}
public function persist(User $entity): void {
// 永続化処理
}
}
class UserSerializer implements ISerializer {
const type TEntity = User;
public function serialize(User $entity): string {
return \Json\encode($entity);
}
public function unserialize(string $raw): User {
$data = \Json\decode_as_array($raw);
return new User((int)$data[‘id’], (string)$data[‘email’]);
}
}
/
- 5. サービスコンテナによるDIの構築
- ジェネリクスではなく、インターフェースのType Constant（this::TEntity）を伝播させる。
/
class UserDataProcessor
where TRepo::TEntity = TSer::TEntity { // ← ここが極限の型安全ポイント！
public function __construct(
private TRepo $repository,
private TSer $serializer,
) {}
public function processAndExport(int $id): string {
$entity = $this->repository->findById($id);
if ($entity === null) {
throw new \RuntimeException(“Entity not found”);
}
// 型チェッカーは $entity が両者の共通の TEntity であることを完全に把握している
return $this->serializer->serialize($entity);
}
}
このコードが美しい理由（テックリードの解説）
1. `where TRepo::TEntity = TSer::TEntity` の強力な型制約
コンストラクタやクラスのジェネリック制約において、異なるリポジトリとシリアライザを渡した際、扱っているドメインモデル（TEntity）が一致しているかをコンパイル時に強制している。もし `UserRepository` と `ProductSerializer` を誤って組み合わせようものなら、Hackの型チェッカーが即座にビルドを弾く。
2. 実行時オーバーヘッドの完全な排除
HHVMのJITコンパイラは、型が静的に確定しているコードに対して最適化（Devirtualizationやインライン展開）を強くかける。`mixed` や動的な `instanceof` チェックを排除することで、PHPの比ではない圧倒的なスループットを実現する。
—
HHVMアーキテクチャの観点：なぜこれがパフォーマンスに寄与するのか
動的言語や、見せかけだけの型なしDIコンテナは、実行時にメソッドのディスパッチや型アサーションを行う。これはHHVMのTC（Translation Cache：ネイティブ機械語キャッシュ）において、プロファイル誘導最適化（PGO）の効率を低下させる要因になる。
HackのType Constantsと厳格な型制約を組み合わせたコードは、HHVMの型推論エンジン（Typeinference）に対して「この変数が取りうる型はこれ以外に絶対に存在しない」という強烈なヒントを与える。結果として：
- ガード命令（Guard Instructions）の削減: 実行時の型チェック命令がネイティブコードから排除される。
- メモリ効率の向上: ボックス化（Boxing）されたプリミティブや不必要なオブジェクト生成が抑制され、HHVMのメモリマネージャの負荷が軽減される。
—
実務で直面するアンチパターンと対策
現場でType Constantsを導入する際、以下の罠に落ちることがある。
❌ 避けるべき設計：Type Constantsの隠蔽化
具象クラスでどのような型が割り当てられているのかを、深すぎる継承階層の奥底で定義してしまうこと。コードリーディングの際に「このクラスの `TEntity` は一体何なのだ？」と迷宮入りする。
【対策】
ドメインの境界（Bounded Context）ごとにインターフェースを小さく保ち、DIを組み立てるエントリーポイント（コンテナの構築場所）で型を明示的に結びつけること。
—
まとめ：型を制する者がHackを制す
Hackの厳格な静的型システム（Strict Mode）は、単なるバグ発見ツールではない。それは「実行時の不確実性を排除し、コードベースのドメインモデルを数学的なまでに硬い契約で結びつけるための建築様式」である。
今回解説した Type Constants と Where 節による型制約をマスターすれば、大規模なWebアプリケーションであっても、リファクタリングを恐れない圧倒的な堅牢性を手に入れることができる。
次のコードレビューでは、同僚の書いた `mixed` の山を見つけたら、こう問いかけてほしい。
——「おい、その依存関係、Type Constantsで静的に証明できるか？」と。