Java: установить различия интерфейса интерфейса и интерфейса

Question

Я просто посмотрел на интерфейс Set и обнаружил, что он в основном (или полностью) только обновляет функции, которые уже находятся в интерфейсе Collection. Set сам расширяет Collection, поэтому это не означает, что интерфейс Set автоматически выполняет все функции от Collection? Так почему же они были обьяснены?

Например, Set redeclares это:

/** 
* Returns the number of elements in this set (its cardinality). If this 
* set contains more than <tt>Integer.MAX_VALUE</tt> elements, returns 
* <tt>Integer.MAX_VALUE</tt>. 
* 
* @return the number of elements in this set (its cardinality) 
*/ 
int size(); 

/** 
* Returns <tt>true</tt> if this set contains no elements. 
* 
* @return <tt>true</tt> if this set contains no elements 
*/ 
boolean isEmpty(); 

И декларация в Collection:

/** 
* Returns the number of elements in this collection. If this collection 
* contains more than <tt>Integer.MAX_VALUE</tt> elements, returns 
* <tt>Integer.MAX_VALUE</tt>. 
* 
* @return the number of elements in this collection 
*/ 
int size(); 

/** 
* Returns <tt>true</tt> if this collection contains no elements. 
* 
* @return <tt>true</tt> if this collection contains no elements 
*/ 
boolean isEmpty(); 

Это кажется очень избыточными для меня. Почему бы не просто определить интерфейс Set как:

public interface Set<E> extends Collection<E> {} 

Я думаю, что нет ни одного различия между этими интерфейсами, не так ли?

---

Конечно, я не спрашиваю о другом семантикой/значении Set. Я знаю это. Я просто спрашиваю, имеет ли это технически (т. Е. Компилятору) какую-либо разницу. Т.е., вообще говоря:

interface A { void foo(); } 
interface B extends A { void foo(); } 
interface C extends A {} 

Теперь, есть ли разница между A, B или C?

---

Хотя контракт (т.е. то, что сказано в документации) действительно может быть различным для некоторых функций (как для add), есть веская причина, чтобы переопределить их: Для того, чтобы иметь возможность поставить новую документацию, т.е. определить новый контракт.

Однако есть также функции (например, isEmpty), которые имеют точно такую ​​же документацию/контракт. Почему они также переоформлены?

Answer 1

Технически для компилятора это не имеет никакого значения.

Однако набор не может иметь повторяющиеся записи, тогда как коллекция может. Об этом стоит знать.

Из-за этого семантика методов для параметров, возвращаемых значений и событий может означать разные вещи. Redeclaring также позволяет javadoc стать более конкретным.Например, для добавления():

Set: @return верно, если этот набор уже не содержат указанный элемент

Коллекция: @return верно, если эта коллекция изменилась в результате вызова

The значение для множества более конкретно.

Даже для методов, которые не являются более конкретными, это позволяет javadoc быть более приятным. Например, для size(): «Возвращает количество элементов в этом наборе (его мощность)». который ближе к языку, который люди, привыкшие к математическим наборам, поймут.

В документах API обобщается это: «Интерфейс« Установка »устанавливает дополнительные условия, помимо тех, что унаследованы от интерфейса Collection, от контрактов всех конструкторов и контрактов методов add, equals и hashCode. другие удобства унаследованы также для удобства. (Спецификации, прилагаемые к этим объявлениям, были адаптированы к интерфейсу Set, но они не содержат каких-либо дополнительных условий.) «

Answer 2

Ответ представлен в API java6 для набора.

«Интерфейс« Установка »устанавливает дополнительные условия, помимо тех, что унаследованы от интерфейса Collection, от контрактов всех конструкторов и контрактов методов add, equals и hashCode. Объявления для других унаследованных методов также включены сюда для удобства . (Спецификации, прилагаемые к этим объявлениям, были адаптированы к интерфейсу Set, но они не содержат никаких дополнительных условий.) «

Answer 3

Существует больше способа, чем его подпись.

В этом случае документация этих методов была адаптирована к наборам с точки зрения пред- и пост-условий и терминологии.

Answer 4

Они переоформлены, потому что, даже если имена одинаковы, они имеют различный смысл. Метод add в Set представляет собой конкретный вариант общего метода add в Collection.

Целью является прямое указание, что метод add os Set сильно отличается от метода добавления Collection.

Почему бы не просто определить интерфейс Установить как:

public interface Set<E> extends Collection<E> {} 

Если это было сделано таким образом, не было бы места, где могут быть указаны контракт из Set. Как я узнаю, что, применяя метод add для Set, я не должен допускать дубликатов?