Суперкласс как тип appernt в списке [duplicate]

другое решение состоит в создании нового списка

List<Dog> dogs = new ArrayList<Dog>(); 
List<Animal> animals = new ArrayList<Animal>(dogs);
animals.add(new Cat());

Проблема была хорошо идентифицирована. Но есть решение; make doSomething generic:

<T extends Animal> void doSomething<List<T> animals) {
}

теперь вы можете вызвать doSomething с помощью List & lt; Dog> или List & lt; Cat> или List & lt; Animal>.

Ответы здесь не полностью меня убедили. Поэтому вместо этого я делаю еще один пример.

public void passOn(Consumer<Animal> consumer, Supplier<Animal> supplier) {
    consumer.accept(supplier.get());
}

звучит нормально, не так ли? Но вы можете передавать только Consumer s и Supplier s для Animal s. Если у вас есть потребитель Mammal, но поставщик Duck, они не должны соответствовать, хотя оба являются животными. Чтобы отменить это, добавлены дополнительные ограничения.

Вместо вышесказанного мы должны определить отношения между используемыми нами типами.

E. g.,

public <A extends Animal> void passOn(Consumer<A> consumer, Supplier<? extends A> supplier) {
    consumer.accept(supplier.get());
}

гарантирует, что мы можем использовать только поставщика, который предоставляет нам правильный тип объекта для потребителя.

OTOH, мы могли бы также сделать

public <A extends Animal> void passOn(Consumer<? super A> consumer, Supplier<A> supplier) {
    consumer.accept(supplier.get());
}

, где мы идем в другую сторону: мы определяем тип Supplier и ограничиваем, что его можно поместить в Consumer.

Мы даже можем сделать

public <A extends Animal> void passOn(Consumer<? super A> consumer, Supplier<? extends A> supplier) {
    consumer.accept(supplier.get());
}

где, имея интуитивные отношения Life -> Animal -> Mammal -> Dog, Cat и т. д., мы могли бы даже поставить Mammal в Life, но не String в потребителя Life.

Причина, по которой List<Dog> не является List<Animal>, заключается в том, что вы можете вставить Cat в List<Animal>, но не в List<Dog> ... вы можете использовать подстановочные знаки для по возможности расширять дженерики; например, чтение из List<Dog> похоже на чтение с List<Animal> - но не на запись.

Общие для Java-языка и Раздел «Общие» из учебников Java содержит очень хорошее, подробное объяснение того, почему некоторые вещи являются или не являются полиморфными или разрешены с помощью дженериков.

Чтобы понять проблему, полезно сделать сравнение с массивами.

List<Dog> не является подклассом List<Animal>. Но Dog[] является подклассом Animal[].

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

    // All compiles but throws ArrayStoreException at runtime at last line
    Dog[] dogs = new Dog[10];
    Animal[] animals = dogs; // compiles
    animals[0] = new Cat(); // throws ArrayStoreException at runtime

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

    List<Dog> dogs = new ArrayList<>();
    List<Animal> animals = dogs; // compile-time error, otherwise heap pollution
    animals.add(new Cat());

Подтипирование является инвариантом для параметризованных типов. Даже жесткий класс Dog является подтипом Animal, параметризованный тип List<Dog> не является подтипом List<Animal>. Напротив, подтипирование covariant используется массивами, поэтому тип массива Dog[] является подтипом Animal[].

Инвариантный подтипирование гарантирует, что ограничения типа, принудительно выполняемые Java, не нарушены. Рассмотрим следующий код, приведенный @Jon Skeet:

List<Dog> dogs = new ArrayList<Dog>(1);
List<Animal> animals = dogs;
animals.add(new Cat()); // compile-time error
Dog dog = dogs.get(0);

Как указано в @Jon Skeet, этот код является незаконным, поскольку в противном случае он будет нарушать ограничения типа, возвращая кошку, когда ожидается собака.

Поучительно сравнить приведенное выше с аналогичным кодом для массивов.

Dog[] dogs = new Dog[1];
Object[] animals = dogs;
animals[0] = new Cat(); // run-time error
Dog dog = dogs[0];

Код является законным. Тем не менее, выбрасывает исключение хранилища . Массив носит свой тип во время выполнения таким образом, JVM может обеспечить безопасность типов ковариантного подтипирования.

Чтобы понять это далее, давайте посмотрим на байт-код, сгенерированный javap класса ниже:

import java.util.ArrayList;
import java.util.List;

public class Demonstration {
    public void normal() {
        List normal = new ArrayList(1);
        normal.add("lorem ipsum");
    }

    public void parameterized() {
        List<String> parameterized = new ArrayList<>(1);
        parameterized.add("lorem ipsum");
    }
}

Используя команду javap -c Demonstration, это показывает следующий байт-код Java:

Compiled from "Demonstration.java"
public class Demonstration {
  public Demonstration();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public void normal();
    Code:
       0: new           #2                  // class java/util/ArrayList
       3: dup
       4: iconst_1
       5: invokespecial #3                  // Method java/util/ArrayList."<init>":(I)V
       8: astore_1
       9: aload_1
      10: ldc           #4                  // String lorem ipsum
      12: invokeinterface #5,  2            // InterfaceMethod java/util/List.add:(Ljava/lang/Object;)Z
      17: pop
      18: return

  public void parameterized();
    Code:
       0: new           #2                  // class java/util/ArrayList
       3: dup
       4: iconst_1
       5: invokespecial #3                  // Method java/util/ArrayList."<init>":(I)V
       8: astore_1
       9: aload_1
      10: ldc           #4                  // String lorem ipsum
      12: invokeinterface #5,  2            // InterfaceMethod java/util/List.add:(Ljava/lang/Object;)Z
      17: pop
      18: return
}

Обратите внимание, что переведенный код тел метода идентичен. Компилятор заменил каждый параметризованный тип на erasure . Это свойство имеет решающее значение, поскольку оно не нарушает совместимость в обратном направлении.

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

Ответ , а также другие ответы правильные. Я собираюсь добавить к этим ответам решение, которое, я думаю, будет полезно. Я думаю, что это часто возникает при программировании. Следует отметить, что для коллекций (списки, наборы и т. Д.) Основной проблемой является добавление в коллекцию. Вот где вещи ломаются. Даже удаление в порядке.

В большинстве случаев мы можем использовать Collection<? extends T>, а не Collection<T>, и это должен быть первый выбор. Однако я нахожу случаи, когда это непросто сделать. Он обсуждает вопрос о том, всегда ли это самое лучшее. Я представляю здесь класс DownCastCollection, который может преобразовать Collection<? extends T> в Collection<T> (мы можем определить аналогичные классы для List, Set, NavigableSet, ..), которые будут использоваться, когда использование стандартного подхода очень неудобно. Ниже приведен пример того, как его использовать (мы могли бы также использовать Collection<? extends Object> в этом случае, но я просто не могу проиллюстрировать использование DownCastCollection.

/**Could use Collection<? extends Object> and that is the better choice. 
* But I am doing this to illustrate how to use DownCastCollection. **/

public static void print(Collection<Object> col){  
    for(Object obj : col){
    System.out.println(obj);
    }
}
public static void main(String[] args){
  ArrayList<String> list = new ArrayList<>();
  list.addAll(Arrays.asList("a","b","c"));
  print(new DownCastCollection<Object>(list));
}

Теперь класс:

import java.util.AbstractCollection;
import java.util.Collection;
import java.util.Iterator;
import java.util.NoSuchElementException;

public class DownCastCollection<E> extends AbstractCollection<E> implements Collection<E> {
private Collection<? extends E> delegate;

public DownCastCollection(Collection<? extends E> delegate) {
    super();
    this.delegate = delegate;
}

@Override
public int size() {
    return delegate ==null ? 0 : delegate.size();
}

@Override
public boolean isEmpty() {
    return delegate==null || delegate.isEmpty();
}

@Override
public boolean contains(Object o) {
    if(isEmpty()) return false;
    return delegate.contains(o);
}
private class MyIterator implements Iterator<E>{
    Iterator<? extends E> delegateIterator;

    protected MyIterator() {
        super();
        this.delegateIterator = delegate == null ? null :delegate.iterator();
    }

    @Override
    public boolean hasNext() {
        return delegateIterator != null && delegateIterator.hasNext();
    }

    @Override
    public  E next() {
        if(!hasNext()) throw new NoSuchElementException("The iterator is empty");
        return delegateIterator.next();
    }

    @Override
    public void remove() {
        delegateIterator.remove();

    }

}
@Override
public Iterator<E> iterator() {
    return new MyIterator();
}



@Override
public boolean add(E e) {
    throw new UnsupportedOperationException();
}

@Override
public boolean remove(Object o) {
    if(delegate == null) return false;
    return delegate.remove(o);
}

@Override
public boolean containsAll(Collection<?> c) {
    if(delegate==null) return false;
    return delegate.containsAll(c);
}

@Override
public boolean addAll(Collection<? extends E> c) {
    throw new UnsupportedOperationException();
}

@Override
public boolean removeAll(Collection<?> c) {
    if(delegate == null) return false;
    return delegate.removeAll(c);
}

@Override
public boolean retainAll(Collection<?> c) {
    if(delegate == null) return false;
    return delegate.retainAll(c);
}

@Override
public void clear() {
    if(delegate == null) return;
        delegate.clear();

}

}

Если вы уверены, что элементы списка являются подклассами этого суперпорогового типа, вы можете использовать список, используя этот подход:

(List<Animal>) (List<?>) dogs

Это полезно, когда вы хотите передать список в конструкторе или перебрать его

Базовая логика такого поведения заключается в том, что Generics следует механизму стирания типа. Поэтому во время выполнения вы не можете определить тип collection в отличие от arrays, где нет такого процесса стирания. Итак, вернемся к вашему вопросу ...

Итак, предположим, что существует метод, приведенный ниже:

add(List<Animal>){
    //You can add List<Dog or List<Cat> and this will compile as per rules of polymorphism
}

Теперь, если java позволяет вызывающему добавить список типов Animal к этому методу то вы можете добавить неправильную вещь в коллекцию, и во время выполнения тоже она будет запущена из-за стирания типа. В то время как в случае массивов вы получите исключение времени выполнения для таких сценариев ...

Таким образом, по существу это поведение реализовано таким образом, что нельзя добавлять неправильную вещь в коллекцию. Теперь я считаю, что стирание стилей существует, чтобы обеспечить совместимость с устаревшим java без дженериков ....