Best way to check if all elements in a List are unique
in [Java Programming]
|
From: Roedy Green on 3 Mar 2010 23:19 On Tue, 02 Mar 2010 08:59:04 -0500, Eric Sosman <esosman(a)ieee-dot-org.invalid> wrote, quoted or indirectly quoted someone who said : > > List<String> list = new ArrayList<String>(); > for (int i = 0; i < 100; ++i) > list.add(new String("unique")); > >? Both "one" and "one hundred" are reasonable answers. Well done! I wanted to explain that, but started tripping over my words and ended up deleting my explanation, thinking it would confuse more than elaborate. You nailed it succinctly and clearly. -- Roedy Green Canadian Mind Products http://mindprod.com The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair. ~ Douglas Adams (born: 1952-03-11 died: 2001-05-11 at age: 49)
From: Lew on 7 Mar 2010 23:32 Tom Anderson wrote: > I ... > read your comment as suggesting that the method should null-check the > incoming argument. That's what I recommended, yes. > The right thing for this method to do if passed a null argument is to > throw an exception. There is no uncertainty about that. And it already > does that, so no check is necessary. Not necessarily. As Mike pointed out, some action may be needed upon discerning a null. To his example, for example, I'd add logging in some scenarios. The method may be one whose contract is to deliver some default value, such as Mike's suggestion for the OP's case boolean areListElementsUnique(List<?> l) that a null argument be deemed trivially as containing no duplicate elements. There is no reason for that check method to throw an NPE when it could reasonably return 'true'. If that were the contract, the method would need the null check. If that were not the contract, but the contract were to throw NPE or IllegalArgumentException or MyApplicationException, then it would do that. -- Lew
From: luc peuvrier on 8 Mar 2010 01:33 On Mar 3, 1:08 am, Lew <no...(a)lewscanon.com> wrote: > Mike Schilling wrote: > >>>> boolean areListElementsUnique(List<?> l) > >>>> { > >>>> return l.size() == new HashSet<Object>(l).size(); > >>>> } > laredotornado wrote: > >>> Winner! - > Lew wrote: > >> Don't forget to null-check the argument! > Tom Anderson wrote: > > The method already does that - if it's null, you get a > > NullPointerException. > > Umm, the point of my comment was to *avoid* the NPE, duhh. Why cause trouble > for the method's client? > > -- > Lew with this: <T> boolean areListElementsUnique( List<T> list ) { if (list == null || list.size() == 1 ) { return true; } return list.size() == new HashSet <T> (list).size(); } if list is null, areListElementsUnique return true, saying "list with unique elemen", but list is null, not a single element list. There is also the empty list case Luc
From: Tom Anderson on 8 Mar 2010 16:56 On Sun, 7 Mar 2010, Lew wrote: > Tom Anderson wrote: >> I ... read your comment as suggesting that the method should null-check >> the incoming argument. > > That's what I recommended, yes. > >> The right thing for this method to do if passed a null argument is to throw >> an exception. There is no uncertainty about that. And it already does that, >> so no check is necessary. > > Not necessarily. > > As Mike pointed out, some action may be needed upon discerning a null. To > his example, for example, I'd add logging in some scenarios. The method may > be one whose contract is to deliver some default value, such as Mike's > suggestion for the OP's case > > boolean areListElementsUnique(List<?> l) > > that a null argument be deemed trivially as containing no duplicate elements. > There is no reason for that check method to throw an NPE when it could > reasonably return 'true'. I honestly can't imagine a situation where it would be reasonable for it to do that. If your design involves passing around nulls to represent empty lists, or lists in some other way not containing duplicates, then your design is broken. tom -- The future is still out there, somewhere.
From: Mike Schilling on 9 Mar 2010 02:17
Tom Anderson wrote: > On Sun, 7 Mar 2010, Lew wrote: > >> Tom Anderson wrote: >>> I ... read your comment as suggesting that the method should >>> null-check the incoming argument. >> >> That's what I recommended, yes. >> >>> The right thing for this method to do if passed a null argument is >>> to throw an exception. There is no uncertainty about that. And it >>> already does that, so no check is necessary. >> >> Not necessarily. >> >> As Mike pointed out, some action may be needed upon discerning a >> null. To his example, for example, I'd add logging in some >> scenarios. The method may be one whose contract is to deliver some >> default value, such as Mike's suggestion for the OP's case >> >> boolean areListElementsUnique(List<?> l) >> >> that a null argument be deemed trivially as containing no duplicate >> elements. That wasn't my suggestion. >> There is no reason for that check method to throw an NPE >> when it could reasonably return 'true'. > > I honestly can't imagine a situation where it would be reasonable for > it to do that. If your design involves passing around nulls to > represent empty lists, or lists in some other way not containing > duplicates, then your design is broken. I agree. A null isn't a List, and should throw an NPE. |