I want to add objects to a collection. Then if the object is a duplicate I want to pull the object out of the collection modify it and put it back. I was thinking a Set since Sets don't allow duplicates. Any ideas? Thanks, Tom
A Set would work, but it would take too much work to make it work. A Set doesn't have direct access to its members, so you wouldn't be able to detect that the member already existed then pull it out and modify it very easily.
What I typically do is something along these lines:
[ November 29, 2005: Message edited by: Ray Stojonic ]
I want to pull the object out of the collection modify it and put it back.
You don't need to do that. At least, not all of it.
First of all, you can't get the object from a Set. All you can do is find if the Set already contains the object, and add it if it doesn't. But notice that you already have a reference to the object in either case, and so does the Set. You can just modify the object, you don't need to try adding it to the set again. That would just do nothing.
I'm not clear on what you're saying. I tried to say it in Java: I should add that your notion of "duplicate" must be captured by your object's equals() method. That is part of the Set contract. [ November 29, 2005: Message edited by: Jeff Albrechtsen ]
There is no emoticon for what I am feeling!
Joined: Sep 16, 2005
Originally posted by Paul Clapham:
I think this code is assuming that obj1.equals(obj2) implies obj1==obj2. if that's the case, you're ok, but if not, then if add returns false you can't assume that the collection contains a *reference* to the given object -- it just contains a reference to an *equal* object.
As mentioned in a previous reply, you don't need to add the object back to the collection. When you call the get method, you get back a reference to the object that is in the collection. It does not remove the object from the collection. You simply need to modify the object once you have a reference to it. Thus, the last line of code (hm.put(key, obj)) is unnecessary.
I'm glad to see Tom has shifted from Set to Map, because the idea of changing fields of an object in a Set is asking for trouble, I think. Objects in a Set should really be immutable, or at least treated as though they're immutable (i.e. don't use any setters or other mutators after putting the object in the Set). Same for objects used as keys in a Map. Both Sets and Maps are written with the assumption that these objects won't change their fields after they've been inserted. If you change them, things start to break in weird ways.
On the other hand, changing the fields of an object which is used as the value in a Map - that's fine. Great. No problem.
"I'm not back." - Bill Harding, Twister
Joined: Sep 16, 2005
Good points, Jim. I take back what I said about using Set. Unless your objects have no clear key, you should start with a Map.