File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes Why do List and Set interfaces re-define methods of Collection interface? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Why do List and Set interfaces re-define methods of Collection interface?" Watch "Why do List and Set interfaces re-define methods of Collection interface?" New topic
Author

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

Anil Chatty
Greenhorn

Joined: Jun 12, 2007
Posts: 21
java.util.List and java.util.Set extend java.util.Collection.

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


SCJP 5.
Jelle Klap
Bartender

Joined: Mar 10, 2008
Posts: 1796
    
    7

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.


Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19726
    
  20

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.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Jim Hoglund
Ranch Hand

Joined: Jan 09, 2008
Posts: 525
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 ... ...


BEE MBA PMP SCJP-6
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19726
    
  20

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

Joined: Jun 12, 2007
Posts: 21
Thanks guys for your valuable inputs
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4659
    
    5

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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Why do List and Set interfaces re-define methods of Collection interface?