皆さん、こんにちは！Hack言語の深遠な世界へようこそ。チーフアーキテクトとして、皆さんのHack学習を全力でサポートさせていただきます。
今回は、Hackの厳格な静的型付けシステムの中でも、特にジェネリクスを扱う上で避けては通れない、そして一度理解すればコードの堅牢性が格段に向上する『共変性（Covariance）』と『反変性（Contravariance）』について、その本質をじっくりと解き明かしていきます。
「変位って何だか難しそう…」と感じるかもしれませんね。でも大丈夫！その数学的な背景から、Hackの型チェッカーがどのように型安全性を保証しているのかまで、図解的な表現や具体的なコード例を交えながら、優しく、そして深く解説していきます。
ここをクリアすれば、Hackのジェネリクスをまさに「掌握」したと言えるでしょう。さあ、一緒にこの謎を解き明かしていきましょう！
—
目次
1. Hackの静的型付けとジェネリクスのおさらい
2. 「変位（Variance）」とは何か？
3. 共変性（Covariance）：『出力』の型パラメータのルール
- なぜ『共変』だと型安全なのか？
- Hackにおける`out`アノテーション
- コード例で理解する共変性
4. 反変性（Contravariance）：『入力』の型パラメータのルール
- なぜ『反変』だと型安全なのか？
- Hackにおける`in`アノテーション
- コード例で理解する反変性
5. 不変性（Invariance）：どちらでもない場合
6. なぜHackは`in`と`out`を明示させるのか？：型チェッカーの厳格な保証
7. 実践的なヒントとよくある間違い
8. まとめ：Hackの型システムを味方につける
—
1. Hackの静的型付けとジェネリクスのおさらい
Hackは、PHPから派生した言語でありながら、その上に極めて厳格な静的型システムを構築しています。特に`declare(strict_types=1);`と`// hh_client –strict`で有効になるStrict Modeでは、コンパイル時に可能な限り多くの型エラーを検出することで、実行時エラーのリスクを劇的に減らしてくれます。これは、大規模なアプリケーション開発において、非常に大きなアドバンテージになりますよね。
その厳格な型システムをさらに強力にするのがジェネリクスです。
例えば、`Vector
{
private T $value;
public function __construct(T $value) {
$this->value = $value;
}
public function getValue(): T {
return $this->value;
}
public function setValue(T $value): void {
$this->value = $value;
}
}
function main(): void {
// 文字列を格納するBox
$stringBox = new Box(‘Hello Hack!’);
$stringVal: string = $stringBox->getValue();
echo “String Box: ” . $stringVal . “\n”;
// 整数を格納するBox
$intBox = new Box(123);
$intVal: int = $intBox->getValue();
echo “Int Box: ” . $intVal . “\n”;
// $stringBox->setValue(456); // 型エラー！intはstringに代入できない
}
main();
この`Box
もし`Animal`クラスとそれを継承した`Dog`クラスがあったとして、`Box
「`Dog`は`Animal`の子だから、`Box
…実は、必ずしもそうはなりません。そして、その「ならない」理由こそが、型安全性を保つための重要な鍵なんです。
2. 「変位（Variance）」とは何か？
「変位（Variance）」とは、ジェネリック型（例: `Box
言葉で聞くと少し難しいですよね。簡単に言うと、
- `Child` が `Parent` のサブタイプ（子クラス）であるとき、
- `Generic
` が `Generic ` のサブタイプになるのか？ - それとも `Generic
` が `Generic ` のサブタイプになるのか？ - はたまた、全く関係ないのか？
この関係性を決定するのが「変位」なんです。そして、この変位には以下の3種類があります。
1. 共変性（Covariance）: `Generic
2. 反変性（Contravariance）: `Generic
3. 不変性（Invariance）: `Generic
Hackでは、この変位を明示的に指定しないと、デフォルトで「不変性」になります。そして、その明示のために`in`と`out`というキーワードを使うんです。
3. 共変性（Covariance）：『出力』の型パラメータのルール
なぜ『共変』だと型安全なのか？
共変性は、主にジェネリック型から値を取り出す（出力する）場合に適用されます。
「共変（Co-variance）」という名前の通り、型パラメータのサブタイプ関係と、ジェネリック型自体のサブタイプ関係が「同じ向き」に進むイメージです。
つまり、`Child`が`Parent`のサブタイプである場合、`Generic
例: `Dog`は`Animal`のサブタイプです。
このとき、もし`Vector
// 仮に共変だとすると…
function processAnimals(Vector
// …
}
$dogs = Vector {new Dog(), new Dog()};
processAnimals($dogs); // Vector
これは安全ですよね？ `Vector
これがもし逆だったらどうでしょう？ `Vector
`Vector
だから、「出力」の型パラメータは、より特殊化された型（子孫の型）を返す方が安全なんです。
Hackにおける`out`アノテーション
Hackでは、型パラメータが共変であることを示すために`out`キーワードを使用します。これは、「この型パラメータは、このジェネリック型から値を出力するためにのみ使われます」ということを型チェッカーに明示するサインです。
{ // ここがポイント: +Tout (out)
public function produce(): Tout;
}
// Animalを生成するクラス
class AnimalProducer implements IProducer
public function produce(): Animal {
return new Animal();
}
}
// Dogを生成するクラス
class DogProducer implements IProducer
public function produce(): Dog {
return new Dog();
}
}
function feedAnimal(IProducer
$animal = $producer->produce();
echo “Feeding an animal…\n”;
}
function main(): void {
$animalProducer = new AnimalProducer();
$dogProducer = new DogProducer();
// IProducer
// なぜなら、DogはAnimalの子であり、IProducer
feedAnimal($animalProducer);
feedAnimal($dogProducer); // これはOK！
// 逆に、IProducer
// $animalProducer_as_dog_producer: IProducer
// $animalProducer_as_dog_producer->produce(); // Animalが返ってきてしまい、Dogを期待する場所で困る
echo “Done.\n”;
}
main();
実行結果:
Feeding an animal…
Feeding an animal…
Done.
上記のコードでは、`IProducer<+Tout>`と定義することで、`Tout`が共変であることを明示しています。
これにより、`DogProducer`が`IProducer
4. 反変性（Contravariance）：『入力』の型パラメータのルール
なぜ『反変』だと型安全なのか？
反変性は、主にジェネリック型に値を渡す（入力する）場合に適用されます。
「反変（Contra-variance）」という名前の通り、型パラメータのサブタイプ関係と、ジェネリック型自体のサブタイプ関係が「逆の向き」に進むイメージです。
つまり、`Child`が`Parent`のサブタイプである場合、`Generic
例: `Dog`は`Animal`のサブタイプです。
このとき、もし`Comparator
// 仮に反変だとすると…
function sortDogs(Comparator
// $comparatorを使って$dogsをソート
}
$animalComparator = new AnimalComparator(); // Animalを比較できるComparator
sortDogs($animalComparator, $dogs); // Comparator
これは安全ですよね？ `Comparator
これがもし逆だったらどうでしょう？ `Comparator
`Comparator
だから、「入力」の型パラメータは、より汎化された型（祖先の型）を受け取る方が安全なんです。
Hackにおける`in`アノテーション
Hackでは、型パラメータが反変であることを示すために`in`キーワードを使用します。これは、「この型パラメータは、このジェネリック型へ値を入力するためにのみ使われます」ということを型チェッカーに明示するサインです。
{ // ここがポイント: -Tin (in)
public function consume(Tin $item): void;
}
// Animalを受け取るコンシューマー
class AnimalConsumer implements IConsumer
public function consume(Animal $item): void {
echo “Consuming an ” . (string)$item . “.\n”;
}
}
// Dogを受け取るコンシューマー
class DogConsumer implements IConsumer
public function consume(Dog $item): void {
echo “Consuming a ” . (string)$item . “.\n”;
}
}
function processDogs(IConsumer
$consumer->consume($dog);
}
function main(): void {
$animalConsumer = new AnimalConsumer();
$dogConsumer = new DogConsumer();
$myDog = new Dog();
$myCat = new Cat();
$myAnimal = new Animal();
// IConsumer
// なぜなら、AnimalConsumerはAnimalを受け取れるので、Dog (Animalの子) も問題なく受け取れるから。
processDogs($animalConsumer, $myDog); // これはOK！
processDogs($dogConsumer, $myDog); // こちらもOK
// 逆に、IConsumer
// $dogConsumer_as_animal_consumer: IConsumer
// $dogConsumer_as_animal_consumer->consume($myCat); // Dogしか受け取れないコンシューマーにCatを渡そうとするのは危険
// $dogConsumer_as_animal_consumer->consume($myAnimal); // Dogしか受け取れないコンシューマーにAnimalを渡そうとするのも危険
echo “Done.\n”;
}
main();
実行結果:
Consuming a Dog.
Consuming a Dog.
Done.
上記のコードでは、`IConsumer<-Tin>`と定義することで、`Tin`が反変であることを明示しています。
これにより、`AnimalConsumer`が`IConsumer
5. 不変性（Invariance）：どちらでもない場合
Hackでは、`in`も`out`も指定しない型パラメータは、不変（Invariant）と見なされます。
不変とは、型パラメータのサブタイプ関係が、ジェネリック型自体のサブタイプ関係に影響しない、つまり`Generic
例えば、標準の`Vector
なぜなら、`Vector
$animals): void {
// …
}
function main(): void {
$dogs = Vector {new Dog(), new Dog()};
// $animals: Vector
// Vectorは不変なので、Vector
$animals = Vector {new Animal(), new Dog()};
processVectorOfAnimals($animals); // こちらはOK
echo “Done.\n”;
}
main();
`Vector
6. なぜHackは`in`と`out`を明示させるのか？：型チェッカーの厳格な保証
他の言語の中には、型パラメータの変位をコンパイラが自動で推論してくれるものもあります。しかし、Hackでは開発者が`in`と`out`を明示的に指定する必要があります。
これは、Hackの型チェッカーが、開発者の意図を最大限に尊重し、それに基づいて極限の型安全性を保証しようとする設計思想の現れです。
- 明示的な意図: `in`や`out`を付けることで、「この型パラメータは入力専用だよ」「この型パラメータは出力専用だよ」と型チェッカーに明確に伝えています。これにより、型チェッカーは、その型パラメータがそれ以外の用途（例えば、`out`と指定したのに、その型で引数を受け取ろうとする）に使われていないかを厳しくチェックできます。
- 誤用の防止: もし自動推論に任せてしまうと、開発者が意図しない変位が適用され、潜在的な型安全性の問題を見逃してしまう可能性があります。明示的な指定は、そうした誤用を未然に防ぎます。
- コードの可読性: `+T`や`-T`を見るだけで、そのジェネリック型がどのような振る舞いを意図しているのか、一目で理解しやすくなります。
この厳格なアプローチは、大規模かつ複雑なシステムにおいて、予期せぬ実行時エラーをコンパイル時にシャットアウトし、開発者に絶大な安心感をもたらします。Hackの型チェッカーは、ただエラーを見つけるだけでなく、あなたのコードをより強く、より安全にするための最高のパートナーなんです。
7. 実践的なヒントとよくある間違い
- 「生産者（Producer）は共変、消費者（Consumer）は反変」
- 何かを生成して「返す」インターフェースやクラスは、型パラメータを`out`にしましょう。（例: `Iterable<+T>`, `IProducer<+T>`)
- 何かを受け取って「消費する」インターフェースやクラスは、型パラメータを`in`にしましょう。（例: `Comparator<-T>`, `IConsumer<-T>`)
- 入力も出力もするような汎用的なコンテナ（例: `Vector
`, `MutableList `) は、不変（デフォルト）で問題ありません。
- `in`と`out`を間違えると型エラーになる例
{ // +Tin と指定したが、実際はconsumeで入力している
public function consume(Tin $item): void;
}
class DogConsumer implements IWrongConsumer
public function consume(Dog $item): void {
echo “Consuming a Dog.\n”;
}
}
function processAnimals(IWrongConsumer
$consumer->consume($animal);
}
function main(): void {
$myDogConsumer = new DogConsumer();
$myAnimal = new Animal();
// ここで型エラー！
// IWrongConsumer
// processAnimals 関数に渡せない。
// もし渡せてしまうと、DogConsumerはDogしか消費できないのに、Animalを渡されてしまう危険がある。
// processAnimals($myDogConsumer, $myAnimal);
}
このように、`in`と`out`の指定が、その型パラメータの実際の使われ方と一致しない場合、Hackの型チェッカーは厳しくエラーを報告します。これは、あなたのコードが型安全ではないことを教えてくれているサインなんですね。
8. まとめ：Hackの型システムを味方につける
Hackにおける共変性（`out`）と反変性（`in`）は、ジェネリクスを扱う上で非常に強力なツールです。これらを適切に使いこなすことで、
- 型安全性の向上: ジェネリック型における不適切な代入を防ぎ、実行時エラーのリスクを最小限に抑えます。
- 柔軟なコード設計: より汎用的なコードを書きながらも、厳格な型チェックの恩恵を受けられます。
- Liskov Substitution Principle (LSP) の遵守: 継承関係にある型を、その期待される振る舞いに従って安全に置き換えられるようになります。
最初は少し馴染みにくい概念かもしれませんが、「出力は共変（`out`）、入力は反変（`in`）」という原則を覚えておくと、ぐっと理解が深まるはずです。Hackの型チェッカーは、決してあなたを縛るものではありません。むしろ、あなたのコードをより堅牢に、より信頼性の高いものにするための、最高のガードマンであり、最高のガイドなんです。
さあ、皆さんもこの知識を武器に、Hackで最高のアプリケーションを構築していきましょう！
何か不明な点があれば、いつでも質問してくださいね。Hackコミュニティはいつでも皆さんを歓迎しています！