Философия Java3

//: generi cs/IterableFi bonacci.java

// Adapt the Fibonacci class to make it Iterable.

import java.util.*;

public class IterableFibonacci

extends Fibonacci implements Iterable<Integer> { private int n;

public IterableFibonacci(int count) { n = count; } public Iterator<Integer> iteratorO {

return new Iterator<Integer>0 {

public boolean hasNextO { return n > 0; } public Integer next О { n- -;

return Iterabl eFibonacci .this nextO.

}

public void removeO { // He реализован

throw new UnsupportedOperationExceptionO;

}

}:

}

public static void main(String[] args) {

for(int i . new IterableFibonacci(18)) System out printO + " ");

}

} /* Output-

1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584

*///.-

Для использования IterableFibonacci в синтаксисе foreach мы передаем конструктору границу, чтобы метод hasNext знал, когда следует возвращать false.

Параметризованные методы

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

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

Чтобы определить параметризованный метод, следует указать список параметров перед возвращаемым значением:

//• generics/GenericMethods.java

public class GenericMethods { public <T> void f(T x) {

System out println(x.getClass.getNameO);

}

public static void main(String[] args) {

GenericMethods gm = new GenericMethodsО,

gm.f(""); продолжение &

gm f(l); gm.f(l.O); gm.f(l.OF); gm f('c'); gm.f(gm);

}

} /* Output: java.lang.String java.lang Integer java.lang.Double java.lang.Float java.lang.Character GenericMethods *///:-

Класс GenericMethods не параметризован, хотя и класс, и его методы могут быть параметризованными одновременно. Но в данном случае только метод f имеет параметр типа, обозначаемый списком параметров перед возвращаемым значением метода.

Учтите, что при использовании параметризованного класса параметры типов должны указываться при создании экземпляра. Но при использовании параметризованного метода указывать параметры типа йе обязательно, потому что компилятор способен «вычислить» их за вас. Таким образом, вызов f выглядит как обычный вызов метода; создается впечатление, что метод f существует в бесконечном количестве перегруженных версий. При вызове ему даже может передаваться аргумент типа GenericMethods.

Для вызовов f, использующих примитивные типы, в действие вступает механизм автоматической упаковки — примитивные типы автоматически преобразуются в соответствующие объекты. Это позволяет исключить некоторые фрагменты кода, которые были необходимы прежде из-за явного выполнения преобразований.

Вычисление типа аргумента

Параметризацию иногда упрекают в том, что она увеличивает объем кода. Для наглядности возьмем пример holding/MapOfList.java из главы 11. Создание контейнера Map с List выглядит так:

Map<Person, List<? extends Pet» petPeople = new HashMap<Person, Li st<? extends Pet»:

(Ключевое слово extends и вопросительные знаки будут описаны позднее в этой главе.) Казалось бы, эта конструкция избыточна, а компилятор мог бы вычислить один из списков аргументов по-другому. В действительности сделать это он не может, но вычисление аргументов типов все же позволяет немного упростить код. Например, мы можем создать вспомогательную библиотеку с различными статическими методами, содержащими самые распространенные реализации различных контейнеров:

//: net/mindview/uti1/New.java

// Utilities to simplify generic container creation

// by using type argument inference.

package net mindview util; import java util *.

public class New {

public static <K.V> Map<K,V> map { return new HashMap<K.V>;

}

public static <T> List<T> list О { return new ArrayList<T>;

}

public static <T> LinkedList<T> 1 ListО { return new Li nkedLi st<T>.

}

public static <T> Set<T> setО { return new HashSet<T>;

}

public static <T> Queue<T> queueO { return new LinkedList<T>;

}

// Примеры:

public static void main(String[] args) {

Map<String, List<String>> sis = New.mapO; List<String> Is = New listO: Li nkedLi st<String> lis = New.lListO; Set<String> ss = New set; Queue<String> qs = New.queueO;

}

} ///-

Примеры использования представлены в main — вычисление аргументов типов устраняет необходимость в повторении списков параметров. Этот прием можно использовать в holding/MapOfList.java:

II- generics/SimplerPets.java import typeinfo.pets.*; import java util *; import net.mindview.util.*;

public class SimplerPets {

public static void main(String[] args) {

Map<Person, Li st<? extends Pet» petPeople = New map; // Остальное без изменений...

}

} ///.-

Пример интересный, однако трудно сказать, насколько он эффективен в действительности. Человеку, читающему код, придется просмотреть дополнительную библиотеку и разобраться в ее коде. Возможно, вместо этого стоит оставить исходное (пусть и избыточное) определение — как ни парадоксально, этот вариант проще. Хотя, если в стандартную библиотеку Java будет добавлено некое подобие New.java, им можно будет пользоваться.

Вычисление типов не работает ни в каких других ситуациях, кроме присваивания. Если передать результат вызова метода (скажем, New.mapO) в аргументе другого метода, компилятор не пытается выполнить вычисление типа. Вместо этого вызов метода интерпретируется так, как если бы возвращаемое значение присваивалось переменной типа Object. Пример ошибки такого рода:

//: generics/LimitsOfInference.java import typeinfo.pets.*; import java.util.*;

public class LimitsOflnference { static void