I just looked up the Set
interface and found that it mostly (or completely) only redeclares functions which are already in the Collection
interface.
There is more to a method than its signature.
In this case, the documentation of these methods has been tailored to sets, in terms of pre- and post-conditions, and terminology.
They are redeclared because, even if the names are same, they have different meaning. The add
method in the Set
is a specific implementation of the generic add
method in Collection
.
The intention is to explicitly specify that the add
method os the Set
is very different from the add method of Collection
.
Why not just define the Set interface as:
public interface Set<E> extends Collection<E> {}
If it has been done this way, there would be no place where the contract of a Set
can be specified. How would I know that by implementing the add
method of the Set
, I should not allow duplicates?
The answer is in the java6 API for set.
"The Set interface places additional stipulations, beyond those inherited from the Collection interface, on the contracts of all constructors and on the contracts of the add, equals and hashCode methods. Declarations for other inherited methods are also included here for convenience. (The specifications accompanying these declarations have been tailored to the Set interface, but they do not contain any additional stipulations.)"
Technically for the compiler it makes no difference at all.
However, a set cannot have duplicate entries whereas a Collection can. This is worth knowing about.
Because of this, the methods semantics for parameters, return values and what happens can mean different things. Redeclaring also allows the javadoc to become more specific. For example for add():
Set: @return true if this set did not already contain the specified element
Collection: @return true if this collection changed as a result of the call
The meaning for set is more specific.
Even for methods that are not more specific, it enables the javadoc to be nicer. For example, for size() : "Returns the number of elements in this set (its cardinality)." which is closer to the language people used to mathematical sets will understand.
The API documents summarise this by saying: "The Set interface places additional stipulations, beyond those inherited from the Collection interface, on the contracts of all constructors and on the contracts of the add, equals and hashCode methods. Declarations for other inherited methods are also included here for convenience. (The specifications accompanying these declarations have been tailored to the Set interface, but they do not contain any additional stipulations.)"