Читаем Философия Java3 полностью

Первая строка main() создает массив Apple и присваивает его ссылке на массив Fruit. Выглядит логично — Apple является разновидностью Fruit, поэтому массив Apple также одновременно должен быть массивом Fruit.

С другой стороны, если фактическим типом массива является Арр1е[], в массиве можно разместить только Apple или субтип Apple, причем это правило должно соблюдаться как во время компиляции, так и во время выполнения. Но обратите внимание на то, что компилятор также позволит разместить в массиве ссылку на объект Fruit. Для компилятора это вполне логично, потому что он имеет дело со ссылкой Fruit[] — так почему бы не разрешить занести в массив объект Fruit или любого типа, производного от Fruit, — скажем, Orange? Во время компиляции это разрешено. Однако механизм времени выполнения знает, что он имеет дело с Apple [], и при попытке занесения постороннего типа происходит исключение.

Впрочем, для массивов это не создает особых проблем, потому что при вставке объекта неверного типа вы об этом очень быстро узнаете во время выполнения. Но одна из основных целей параметризации как раз и состоит в том, чтобы по возможности переместить выявление подобных ошибок на стадию выполнения. Итак, что же произойдет при использовании параметризованных контейнеров вместо массивов?

//: generics/NonCovariantGenerics.java // {CompileTimeError} (Won't compile) import java.util.*:

public class NonCovariantGenerics {

// Ошибка компиляции: несовместимые типы List flist = new ArrayList(); } ///:-

На первый взгляд это выглядит как утверждение «Контейнер с элементами Apple нельзя присвоить контейнеру с элементами Fruit», но следует вспомнить, что параметризация — это не только контейнеры. В действительности утверждение следует трактовать шире: «Параметризованный тип, в котором задействован тип Apple, нельзя присвоить параметризованному типу, в котором задействован тип Fruit». Если бы, как в случае с массивами, компилятор располагал достаточной информацией и мог понять, что речь идет о контейнерах, он мог бы проявить некоторую снисходительность. Но компилятор такой информацией не располагает, поэтому он отказывается выполнить «восходящее преобразование». Впрочем, это и не является восходящим преобразованием — List с элементами Apple не является «частным случаем» List с элементами Fruit. Первый может хранить Apple и подтипы Apple, а второй — любые разновидности Fruit... да, в том числе и Apple, но от этого он не становится List с элементами Apple, а по-прежнему остается List с элементами Fruit.

Проблема в том, что речь идет о типе контейнера, а не о типе элементов, которые в этом контейнере хранятся. В отличие от массивов, параметризованные типы не обладают встроенной ковариантностью. Это связано с тем, что массивы полностью определяются в языке и для них могут быть реализованы встроенные проверки как во время компиляции, так и во время выполнения, но с параметризованными типами компилятор и система времени выполнения не знают, что вы собираетесь делать с типами и какие правила при этом должны действовать.

Но иногда между двумя разновидностями параметризованных типов все же требуется установить некоторую связь, аналогичную восходящему преобразованию. Именно это и позволяют сделать метасимволы.

//: generics/GenericsAndCovariance.java

import java.util.*;

public class GenericsAndCovariance {

public static void main(String[] args) {

// Метасимволы обеспечивают ковариантность:

List flist = new ArrayList();

// Ошибка компиляции: добавление объекта

// произвольного типа невозможно

// flist.add(new AppleO);

// flist.add(new FruitO);

// flist.add(new ObjectO);

flist.add(null); // Можно, но неинтересно

// Мы знаем, что возвращается по крайней мере Fruit:

Fruit f = flist.get(O);

}

} ///:-

Теперь flist относится к типу List, что можно прочитать как «список с элементами любого типа, производного от Fruit». Однако в действительности это не означает, что List будет содержать именно типы из семейства Fruit. Метасимвол обозначает «некоторый конкретный тип, не указанный в ссылке flist». Таким образом, присваиваемый List должен содержать некий конкретный тип (например, Fruit или Apple), но для восходящего преобразования к flist этот тип несущественен.

Если единственное ограничение состоит в том, что List содержит Fruit или один из его подтипов, но вас не интересует, какой именно, что же с ним можно сделать? Если вы не знаете, какие типы хранятся в List, возможно ли безопасное добавление объекта? Нет, как и в случае с CovariantArrays.java, но на этот раз ошибка выявляется компилятором, а не системой времени выполнения.

Может показаться, что такой подход не совсем логичен — вам не удастся даже добавить Apple в List, в котором, как вы только что указали, должны храниться Apple. Да, конечно, но компилятор-то этого не знает! List вполне может указывать на List.