こんにちは！Hack言語の世界へようこそ。
今日は、他の言語からHackに入ってきた開発者が「おっ、これぞHackの真骨頂だ！」と感動するテーマ、『Constructor Injection（コンストラクタインジェクション）と型安全な依存解決』について深掘りしていきましょう。
世の中にはたくさんのDI（依存性注入）コンテナがあふれていますが、その多くは「動的」に依存関係を解決するため、設定ファイルを書き間違えたり、クラスを削除し忘れたりすると、本番環境にデプロイして初めてエラー（`ReflectionException` や `Class not found` など）に気づくという冷や汗モノのトラブルが起きがちですよね。
しかし、厳格な静的型付け（Strict Mode）を誇るHackでは、型チェッカー（`hh_vm` / `hhcc`）がコンパイル時にすべてを見抜いてくれます。ここをクリアすれば、あなたの書くHackコードの安全性は一段と跳ね上がりますよ。一緒にバッチリマスターしていきましょう！
—
1. コンストラクターインジェクションの基本と「型安全」の正体
そもそも依存性注入（DI）とは、クラス内部で必要な別クラスのインスタンスを「自分でnewする」のではなく、「外部から（コンストラクタなどを通して）渡してもらう」設計手法のことです。
Hackの厳しい静的型システムでは、これを徹底することで、コードの意図がドキュメントなしでも完璧に型として表現されます。
まずは、シンプルな例を見てみましょう。
<<__Strict>>
namespace HackConnoisseur\DI;
// 1. データベース操作を抽象化するインターフェイス
interface DatabaseInterface {
public function fetchUserData(int $userId): array
}
// 2. 実際のデータベース接続クラス
final class MySqlDatabase implements DatabaseInterface {
public function __construct(private string $connectionString) {}
public function fetchUserData(int $userId): array
// 実際にはSQLを発行する処理
return dict[‘id’ => $userId, ‘name’ => ‘Hack Master’];
}
}
// 3. ユーザーサービス（依存を受ける側）
final class UserService {
// コンストラクタでインターフェイス型を要求する（これがコンストラクターインジェクション）
public function __construct(private DatabaseInterface $db) {}
public function getUserProfile(int $userId): array
// 渡された依存オブジェクトのメソッドを安全に呼び出す
return $this->db->fetchUserData($userId);
}
}
ここがポイント！
コンストラクタの引数に `DatabaseInterface $db` と型宣言（Type Hint）が強制されていますよね。Hackの型チェッカーは、「`UserService` をインスタンス化するには、必ず `DatabaseInterface` を実装したオブジェクトが必要である」という契約を静的に検証します。
—
2. ありがちな文法エラーと、Hack型チェッカーの優しい導き
他の言語や動的言語（PHPなど）からやってきた開発者が、よくやりがちなミスを挙げてみましょう。Hackの型チェッカーがどう怒ってくれるのかを知ることは、言語を掌握するうえで最高の近道です。
陥りやすいエラー1：依存の渡し忘れ・型ミスマッチ
次のようなコードを書いたとします。
<<__Strict>>
namespace HackConnoisseur\DI;
function bootstrap(): void {
// エラー例：MySqlDatabaseではなく、まったく関係のない文字列を渡してみる
// $service = new UserService(“not-a-database”);
}
これをHackの型チェッカー（`hh_client`）に通すと、即座に次のようなエラーが返ってきます。
> Type Error:
> Invalid argument (Typing[4110])
> Expected `DatabaseInterface`, got `string`
「おいおい、ここは `DatabaseInterface` が必要なのに、`string` が渡されているよ！」と、型チェッカーがコードを実行する前に教えてくれます。本番環境でクラッシュする未来を、コンパイル時（エディタ上）で完全に防げているわけですね。
—
3. 型安全なDIコンテナ設計：コンパイル時解決の極意
「じゃあ、複雑なオブジェクトのグラフ（依存関係のツリー）はどうやって組み立てればいいの？」という疑問が湧いてきますよね。
Hackの世界では、コンテナ自体も型安全に構築します。手動で配線（Wire up）するか、あるいは静的なファクトリパターンを組み合わせるのが、Hackの硬派なスタイルです。
次のような、型安全なサービスプロバイダのパターンを見てみましょう。
<<__Strict>>
namespace HackConnoisseur\DI;
final class DependencyContainer {
private static ?DatabaseInterface $dbInstance = null;
// シングルトン的だが型安全にインスタンスを管理するファクトリメソッド
public static function getDatabase(): DatabaseInterface {
if (self::$dbInstance === null) {
// 設定値の注入
self::$dbInstance = new MySqlDatabase(“mysql:host=localhost;dbname=hack_db”);
}
return self::$dbInstance;
}
public static function getUserService(): UserService {
// 依存関係を明示的に、かつ型安全に組み立てて返す
return new UserService(self::getDatabase());
}
}
// 実際のアプリケーションエントリーポイント
<<__EntryPoint>>
function main(): void {
// コンテナから完璧に型付けられたサービスを取得
$userService = DependencyContainer::getUserService();
$profile = $userService->getUserProfile(42);
echo “User Name: ” . $profile[‘name’] . “\n”;
}
この設計の美しさ
このアプローチの素晴らしいところは、マジック文字列や実行時リフレクションに頼らず、「すべてのオブジェクトの生成と依存関係が、Hackの型チェッカーの監視下にある」という点です。
もし将来、`MySqlDatabase` のコンストラクタに変更が入り、新しい引数が必須になったとしたらどうでしょう？
Hackの型チェッカーは、`DependencyContainer::getDatabase()` の修正漏れを瞬時に検出し、ビルドを失敗させてくれます。変更に強く、リファクタリングを極限まで怖くなくしてくれる——これこそが、私たちがHackを選ぶ最大の理由です。
—
先輩からのメッセージ
お疲れ様でした！
コンストラクターインジェクションと型安全な依存解決のイメージは掴めましたか？
最初は「型をここまで厳しく書くのは面倒だな」と感じる瞬間があるかもしれません。しかし、大規模なアプリケーションに成長すればするほど、この厳格な型チェッカーは、あなたを夜中に呼び出すバグから守ってくれる最強の相棒へと変わります。
「コンパイルが通るなら、動かした時も絶対に正しい」
この圧倒的な安心感を味わえるようになったら、もうあなたも立派なHackエンジニアです。
ここをクリアしたあなたなら、HHVMのパフォーマンスを最大限に引き出すアーキテクチャの扉をすでに開いています。次のステップも、この調子で楽しくマスターしていきましょう！