Запомните это:
Потребители едят ужин (супер); Производитель продлевает фабрику своего родителя
blockquote>
Существует антишаблон псевдоопределения типа...
class StringList extends ArrayList<String> { }
Хороший материал, допейте!;-)
Как статья отмечает, эта техника имеет некоторые серьезные проблемы, прежде всего, что это "определение типа" является на самом деле отдельным классом и таким образом не может использоваться или наравне с типом, который это расширяет или другие столь же определенные типы.
В общем методе можно использовать ограниченную форму вывода типа для предотвращения некоторых повторений.
Пример: если у Вас есть функция
<K, V> Map<K, V> getSomething() {
//...
}
можно использовать:
final Map<String, Object> something = getsomething();
вместо:
final Map<String, Object> something = this.<String, Object>getsomething();
Используйте Шаблон "фабрика" для создания Дженериков:
Образец метода:
public Map<String, Integer> createGenMap(){
return new HashMap<String,Integer>();
}
Антишаблон псевдоопределения типа, упомянутый Shog9, работал бы - хотя не рекомендуется использовать ANTIPATTERN - но он не обращается к Вашим намерениям. Цель псевдоопределения типа состоит в том, чтобы уменьшить помеху в объявлении и улучшить удобочитаемость.
То, что Вы хотите, должно смочь заменить группу объявлений дженериков одной единственной торговлей. Я думаю, что необходимо остановиться и думать: "в ведьме пути это ценный?". Я имею в виду, я не могу думать о сценарии, где Вам было бы нужно это. Вообразите класс A:
class A {
private Map<String, Integer> values = new HashMap<String, Integer>();
}
Вообразите теперь, когда я хочу изменить поле 'значений' на Карту. Почему существовал бы много других полей, рассеянных через код, для которого нужно то же изменение? Что касается операций, который использует 'значения', которыми простой рефакторинг был бы достаточно.
Нет. Хотя, отличный, язык JVM, с динамическим контролем типов и позволил бы Вам записать:
def map = new HashMap<complicated generic expression>();