views:

1038

answers:

8

Is there any practical difference between a Set and Collection in Java, besides the fact that a Collection can include the same element twice? They have the same methods.

(For example, does Set give me more options to use libraries which accept Sets but not Collections?)

edit: I can think of at least 5 different situations to judge this question. Can anyone else come up with more? I want to make sure I understand the subtleties here.

  1. designing a method which accepts an argument of Set or Collection. Collection is more general and accepts more possibilities of input. (if I'm designing a specific class or interface, I'm being nicer to my consumers and stricter on my subclassers/implementers if I use Collection.)
  2. designing a method which returns a Set or Collection. Set offers more guarantees than Collection (even if it's just the guarantee not to include one element twice). (if I'm designing a specific class or interface, I'm being nicer to my consumers and stricter on my subclassers/implementers if I use Set.)
  3. designing a class that implements the interface Set or Collection. Similar issues as #2. Users of my class/interface get more guarantees, subclassers/implementers have more responsibility.
  4. designing an interface that extends the interface Set or Collection. Very similar to #3.
  5. writing code that uses a Set or Collection. Here I might as well use Set; the only reasons for me to use Collection is if I get back a Collection from someone else's code, or if I have to handle a collection that contains duplicates.
+10  A: 

Collection is also the supertype of List, Queue, Deque, and others, so it gives you more options. For example, I try to use Collection as a parameter to library methods that shouldn't explicitly depend on a certain type of collection.

Generally, you should use the right tool for the job. If you don't want duplicates, use Set (or SortedSet if you want ordering, or LinkedHashSet if you want to maintain insertion order). If you want to allow duplicates, use List, and so on.

Michael Myers
Actually, Collection is not a supertype of Map.
Nathan Kitchen
Ehh, you're right. That wouldn't make much sense, would it?
Michael Myers
How does using a Collection give you *more* options? Using more general things usually give you *less* power.
Martijn
It gives more options to the person calling a method that takes a Collection as parameter because they can pass a List, Set or Queue without having to do any conversion.
Michael Borgwardt
Yes, I was speaking from the point of view of the person writing a method accepting a Collection. For a method *returning* something, I prefer to use the appropriate type for the job, as I said.
Michael Myers
+2  A: 

See Java's Collection tutorial for a good walk-through of Collection usage. In particular, check out the class hierarchy.

Zack
+4  A: 

I think you already have it figured out- use a Set when you want to specifically exclude duplicates. Collection is generally the lowest common denominator, and it's useful to specify APIs that accept/return this, which leaves you room to change details later on if needed. However if the details of your application require unique entries, use Set to enforce this.

Also worth considering is whether order is important to you; if it is, use List, or LinkedHashSet if you care about order and uniqueness.

Caffeine Coma
+1  A: 

You should use a Set when that is what you want.

For example, a List without any order or duplicates. Methods like contains are quite useful.

A collection is much more generic. I believe that what mmyers wrote on their usage says it all.

Tom
+1  A: 

As @mmyers states, Collection includes Set, as well as List.

When you declare something as a Set, rather than a Collection, you are saying that the variable cannot be a List or a Map. It will always be a Collection, though. So, any function that accepts a Collection will accept a Set, but a function that accepts a Set cannot take a Collection (unless you cast it to a Set).

pkaeding
Actually, Map does not extend Collection.
Nathan Kitchen
You are right, my mistake. I just edited the answer to fix this.
pkaeding
+1  A: 

The practical difference is that Set enforces the set logic, i.e. no duplicates and unordered, while Collection does not. So if you need a Collection and you have no particular requirement for avoiding duplicates then use a Collection. If you have the requirement for Set then use Set. Generally use the highest interface possibble.

Vincent Ramdhanie
A: 

One other thing to consider... Sets have extra overhead in time, memory, and coding in order to guarantee that there are no duplicates. (Time and memory because sets are usually backed by a HashMap or a Tree, which adds overhead over a list or an array. Coding because you have to implement the hashCode() and equals() methods.)

I usually use sets when I need a fast implementation of contains() and use Collection or List otherwise, even if the collection shouldn't have duplicates.

Clint Miller
A: 

As Collection is a super type of Set and SortedSet these can be passed to a method which expects a Collection. Collection just means it may or may not be sorted, order or allow duplicates.

Peter Lawrey