こんにちは！Hack言語の世界へようこそ。
世界最高峰のHHVMと厳格な型システムが生み出す圧倒的なパフォーマンスと安全性、その魅力にどっぷり浸かっている頃ではないでしょうか。
他のオブジェクト指向言語（PHP、Java、C#など）を経験した方なら、「ジェネリクス（総称型）」や「インターフェース」の概念はお馴染みですよね。でも、HackのStrict Mode（厳格モード）におけるジェネリクスは、ランタイムの動的な甘えを一切許しません。
今回は、中級者へのステップアップとして不可欠な`where`句によるジェネリクスの制約強化について、優しく、しかし本質を突いたアプローチで解説していきますね。
ここをクリアすれば、あなたの設計するインターフェースの安全性は劇的に跳ね上がります。一緒にマスターしていきましょう！
—
1. なぜ通常のジェネリクス境界（`as`）だけでは足りないのか？
まず、基本のおさらいから始めましょう。
Hackでジェネリクスを使うとき、通常は `as` キーワードを使って「この型を継承・実装したクラスしか受け付けないよ」という境界（Bound）を設けますよね。
例えば、次のようなコードを想像してください。
hhfile
<<__Strict>>
namespace HackGuide;
interface Renderable {
public function render(): string;
}
// 従来の ‘as’ を使ったジェネリクス
class UIRenderer
public function __construct(private T $component) {}
public function output(): string {
return $this->component->render();
}
}
「お、`T as Renderable` で十分に型安全じゃないか！」と思いましたよね？
その通り、クラス単体を対象にする分にはこれでバッチリです。
しかし、あなたが「複数のジェネリック型を組み合わせる複雑なコンポーネント」や「メソッド単位で高度な制約をかけたいインターフェース設計」をしようとした瞬間、この `as` だけでは表現力不足の壁にぶぶつかるのです。
ここで登場するのが、今回の主役である `where` 句 です。
—
2. `where` 句の基本：メソッドやクラスに「追加の制約」を課す
`where` 句を使うと、クラス定義やメソッド定義の後ろに、型パラメータに対する追加の条件を記述できます。これにより、「クラス全体では緩やかに受け取りつつ、特定の操作の時だけ厳格な関係性を強制する」という高度な抽象化が可能になります。
イメージ図で構造を見てみましょう。
[ジェネリッククラス: Container
│
├─ 通常の ‘as’ 制約: 大まかな型の安全性を担保
│
└─【 where 句の出番！】: T1 と T2 の関係性や、
追加のインターフェース実装をピンポイントで強制
言葉だけだと少し抽象的なので、実用的なコード例を見てみましょう。
例えば、「データを比較するリポジトリ」と「エンティティ」を扱う設計を考えてみます。
hhfile
<<__Strict>>
namespace HackGuide;
interface Identifiable {
public function getId(): int;
}
interface Auditable {
public function getLastUpdated(): int;
}
// クラス定義時点ではジェネリクスに複雑な制約は持たせない
class DataProcessor
public function __construct(private T1 $source, private T2 $target) {}
// ここで where 句を使い、T1 は Identifiable、T2 は Auditable であることを強制する！
public function syncAndAudit(): void
where T1 as Identifiable, T2 as Auditable {
// T1の getId() と T2の getLastUpdated() が安全に呼び出せる
echo “Syncing ID: ” . $this->source->getId() . “\n”;
echo “Last updated at: ” . $this->target->getLastUpdated() . “\n”;
}
}
このコードの何が凄いのか？
1. 関心の分離: クラス `DataProcessor` 自体はどんな型（`mixed`に近い柔軟性）でも保持できます。
2. ピンポイントの型安全性: しかし、データを同期・監査する `syncAndAudit()` メソッドを呼び出す瞬間、型チェッカーが `T1` が `Identifiable` を、`T2` が `Auditable` を本当に実装しているかを厳格に検証します。
クラス全体の定義を汚さず、必要な文脈（メソッド）だけで制約を最大化できるのが `where` 句の真骨頂です。
—
3. 陥りやすい文法エラーと型チェッカーの罠
Hackの型チェッカー（hhvmが裏で血眼になって動かしている静的解析エンジン）は非常に優秀ですが、`where` 句を使うときにはいくつかハマりやすいポイントがあります。
罠1: `where` 句を書く位置の勘違い
`where` 句は、クラス定義の末尾、またはメソッドのシグネチャの末尾（波括弧 `{` の前）に書く必要があります。
// ❌ やってはいけない書き方（構文エラー）
class BadExample
// クラスの型パラメータの直後に書くことはできません
}
// ⭕ 正しい書き方
class GoodExample
public function process(T $item): void
where T as Identifiable {
// メソッドシグネチャの最後に配置する
}
}
罠2: 存在しない型パラメータの指定
`where` 句で指定できるのは、そのクラスやメソッドで宣言されているジェネリック型パラメータのみです。外部の未定義の型を持ち出すと、型チェッカーが容赦なくエラーを吐き出します。
—
4. 実戦投入：型安全なファクトリーパターンでの応用
もう少し現場で使える実践的な例を見てみましょう。
「ある入力型 `TInput` を受け取り、特定のインターフェースを実装した出力型 `TOutput` を生成するマッパー」を `where` 句を使って設計します。
hhfile
<<__Strict>>
namespace HackGuide;
interface MappableToDTO {
public function toArray(): dict
}
interface Validator {
public function validate(): bool;
}
// 型安全なパイプライン処理クラス
class Pipeline
public function __construct(private TInput $input) {}
// TInput は Validator であり、かつ TOutput は MappableToDTO であることを
// where 句で美しく強制する
public function processAndExport(): dict
where TInput as Validator, TOutput as MappableToDTO {
// 入力を検証
invariant($this->input->validate(), “Validation failed!”);
// ここで型キャストやインスタンス化のロジックが入る想定
// 例として TOutput を模した処理
// 実際にはここで変換処理を行います
// 型チェッカーは TOutput が toArray() を持っていることを確実に知っている
// return $output->toArray();
return dict[“status” => “success”];
}
}
このように、`where` 句を使いこなすことで、「データの検証（Validator）」と「データの整形（MappableToDTO）」という異なる責任を持つインターフェースを、ジェネリクスを通じて安全に結びつけることができます。
—
まとめ：Hackの厳格さを味方につけよう
今回は、`where` 句を用いたジェネリクスの制約強化について解説しました。
- 通常の `as` 境界: クラスやメソッド全体の大まかな型制限に使う。
- `where` 句: 複数の型パラメータの関係性や、特定のメソッドにおける高度な制約の追加に使う。
他の言語であれば実行時エラー（Runtime Error）になってしまうような複雑なインターフェースのミスマッチも、Hackの厳格な型チェッカーと `where` 句を活用すれば、「コードを書いている瞬間（静的解析時）」にすべて検知できます。
ここをクリアできれば、あなたのHackコードはより堅牢で、他のエンジニアが見ても美しい洗練された設計になりますよ。
ぜひ実際のプロジェクトのアーキテクチャ設計に取り入れてみてくださいね。それでは、次のHackライフへいってらっしゃい！