Интерфейс Collection имеет несколько методов. Интерфейс List расширяет интерфейс Collection. Он объявляет те же методы, что и интерфейс Collection? Почему это так?
Например
interface Collection extends Iterable
{
public abstract int size();
public abstract boolean isEmpty();
public abstract boolean contains(java.lang.Object);
public abstract java.util.Iterator<E> iterator();
public abstract java.lang.Object[] toArray();
public abstract <T extends java/lang/Object> T[] toArray(T[]);
public abstract boolean add(E);
public abstract boolean remove(java.lang.Object);
public abstract boolean containsAll(java.util.Collection<?>);
public abstract boolean addAll(java.util.Collection<? extends E>);
public abstract boolean removeAll(java.util.Collection<?>);
public abstract boolean retainAll(java.util.Collection<?>);
public abstract void clear();
public abstract boolean equals(java.lang.Object);
public abstract int hashCode();
}
и те же методы также присутствуют в интерфейсе List:
public interface List extends Collection
{
public abstract int size();
public abstract boolean isEmpty();
public abstract boolean contains(java.lang.Object);
public abstract java.util.Iterator<E> iterator();
public abstract java.lang.Object[] toArray();
public abstract <T extends java/lang/Object> T[] toArray(T[]);
public abstract boolean add(E);
public abstract boolean remove(java.lang.Object);
public abstract boolean containsAll(java.util.Collection<?>);
public abstract boolean addAll(java.util.Collection<? extends E>);
public abstract boolean removeAll(java.util.Collection<?>);
public abstract boolean retainAll(java.util.Collection<?>);
public abstract void clear();
public abstract boolean equals(java.lang.Object);
public abstract int hashCode();
}
Требуется ли снова записать эти методы в List, если он уже расширяет интерфейс Collection?
Они переписаны так, что они могут быть задокументированы, чтобы указать, как List уточняет контракт этих методов по сравнению с контрактом, указанным в интерфейсе Collection.
Например, метод add() в List документирован, чтобы указать, что элемент добавлен в конец списка. Это не может быть указано в коллекции, так как у Collection нет начала и конца.
Контракты JavaDoc и API несколько меняются или становятся более конкретными, поскольку вы перемещаетесь по наследству по наследству.
Список повторно объявляет эти методы и дает им более конкретный JavaDoc.
Просто для удобства.
То же, что указано в Документах
Интерфейс List устанавливает дополнительные условия, помимо тех, которые указаны в интерфейсе Collection, в контрактах итератора, add, remove, equals и hashCode. Объявления для других унаследованных методов также включены здесь для удобства
Collection<T> - это всего лишь группа элементов.
Сам по себе он не имеет больше требований, чем ссылки на многие элементы, являющиеся его членами.
В базовом java api есть два основных типа коллекций: List<T> и Set<T>.
List<T> имеют дополнительные требования для поддержания определенного порядка (порядок вставки, отсортированный порядок,...) для всех его элементов. Таким образом, если вы запрашиваете элемент N, список всегда будет возвращать тот же элемент для N.
Set<T> не предлагает никаких гарантий по заказу, но предлагает гарантию на уникальность предметов. Элемент A не может быть добавлен дважды в Set или будет отображаться только один раз в наборе.
Вы должны ознакомиться с практикой интерфейса "marker". Serializable является одним из тех, и обычно основным примером является разговор об этом. И List<T> и Set<T> объявляются как таковые, они отмечают коллекцию как та или иную, чтобы сообщить программисту о поведении, которое они могут ожидать от получаемой коллекции.
Пожалуйста, обратитесь к пункту 37 (глава 6) "Эффективная Java" за очень хорошее объяснение того, как это лучше, чем использование аннотаций.
И есть также тот факт, что myCollection instanceof MyInterface быстрее, чем myCollection.getClass().isAnnotationPresent(MyAnnotation.class) или myCollection.getClass().getAnnotation(MyAnnotation.class) != null.
Подписи в методах toArray предполагают, что вы извлекли это из скомпилированных файлов .class. формат файла класса указывает, что файл .class не повторяет методы, унаследованные от суперинтерфейсов, поэтому я подозреваю, что любой инструмент, который вы использовали для их получения, был показывая вам сложный вид; методы на самом деле физически не присутствуют на List.
Коллекция - это всего лишь набор элементов.
Список, кроме списка элементов, добавляет информацию о последовательности к нему.
Когда вы добавляете элемент в коллекцию, вы просто добавляете его. Когда вы добавляете элемент в список, вы можете добавить в позицию n
Когда вы удаляете элемент из коллекции, вы просто удаляете его. Когда вы удаляете элемент из списка, вы можете удалить его в позиции n
Когда вы хотите получить элемент из коллекции, вам нужно итерации. Когда вы хотите получить элемент из списка, вы можете получить в позиции n
Прежде всего интерфейс List наследует все методы Collection, поэтому все методы, которые существуют в интерфейсе Collection, будут также присутствовать в интерфейсе List, но интерфейс List имеет дополнительные методы (проверьте его по ur self), который описывает поведение списка
Это главным образом из-за целей документации, которые они использовали таким образом.
Например
Collection#retainAll
Сохраняет только элементы этой коллекции, которые содержатся в указанной коллекции (дополнительная операция).
List#retainAll
Сохраняет только те элементы в этом списке, которые содержатся в указанной коллекции (дополнительная операция).
Только для целей java doc они так использовали. Но некоторые из методов поведения сами по себе изменились.
For ex.add,remove
Метод удаляет
In List, Removes the first occurrence of the specified element from this list, if it is present (optional operation).
In Collection , Removes a single instance of the specified element from this collection, if it is present (optional operation).
В Java-документе они четко указывают, что реализация List упорядочена.