Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Why do List and Set interfaces re-define methods of Collection interface?

 
Anil Chatty
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
java.util.List and java.util.Set extend java.util.Collection.

Why do they re-define methods of java.util.Collection interface?

 
Jelle Klap
Bartender
Posts: 1951
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Probably because that's the only way to provide more appropiate JavaDoc API documentation specific to that particular collection type, and it keeps the API documentation clear and easy to navigate, because you don't have to jump back and forth between List/Set and Collection.
 
Rob Spoor
Sheriff
Pie
Posts: 20497
54
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's the additional things that make the difference. For instance, Collection.add(E) only specifies that the element must be present afterwards, and the method returns true if it was added. List.add(E) doesn't only specify that the element must be present afterwards, but that it must always be added at the end, and it will always add the element regardless of whether it was already in the List or not. Set.add(E) on the other hand specifies that the element may only be added if it wasn't present before.
 
Jim Hoglund
Ranch Hand
Posts: 525
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Adding to Rob's comment, this emphasizes that the interface contract enforced by the compiler
(the method signatures) is often only part of the story. There can be many related and more
detailed design requirements that must be met in a successful implementation.

Jim ... ...
 
Rob Spoor
Sheriff
Pie
Posts: 20497
54
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jim Hoglund wrote:the interface contract enforced by the compiler (the method signatures) is often only part of the story. There can be many related and more
detailed design requirements that must be met in a successful implementation.

All to true. The following example will compile but is wrong on sooooo many levels:
Therefore it's always important you read the Javadoc of any method you are implementing / overriding.
 
Anil Chatty
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks guys for your valuable inputs
 
Pat Farrell
Rancher
Posts: 4678
7
Linux Mac OS X VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rob Prime wrote:All to true. The following example will compile but is wrong on sooooo many levels:

Wow, that is some of the ugliest and most bugridden code that I've ever looked at in nearly 40 years in this business. At least in bugs per line of code, and in zillions of staff-years it will take to debug and fix if its way up in some library.

I'll be having nightmares for weeks. Shudder
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic