The Artima Developer Community
Sponsored Link

Weblogs Forum
Collection versus Iterator

18 replies on 2 pages. Most recent reply: Dec 7, 2005 7:59 AM by Axl Mattheus

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 18 replies on 2 pages [ « | 1 2 ]
Howard Lovatt

Posts: 321
Nickname: hlovatt
Registered: Mar, 2003

Re: Collection versus Iterator Posted: Jul 17, 2005 8:03 PM
Reply to this message Reply
@Bruce Eckel

> Your suggestion would mean that you would have to
> guard all your code this way, using generics but then
> remembering that erasure removes the type information.

This isn't what I meant. Sorry for not expressing myself clearly. What I meant to imply is that if the checks are necessary in pre-generic code then they are still necessary in generic code if you are going to allow it to be called from pre-generic code. Since the pre-generic compiler won't do the extra checks.

I see this as a very nice feature of erasure, that both pre and post generic code can call each other with little trouble. But it does mean that if the checks are necessary for pre-generic code then they need to be left in when the code is generified if you are still using some pre-generic code.

Another distinct possibility with this code is that they simply ran out of time :)

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Collection versus Iterator Posted: Jul 25, 2005 7:29 PM
Reply to this message Reply
Collection means that you can start with a List, switch to a Set and finish with a Map and never change your API, only the implementation.

While it may not have been your experience to go down such paths, it has been mine. And, I have been trying to switch my tendency to code the implementation Collection class name into my APIs.

This is parallel to the whole interface vs implementation issue. In an SOA, and other public interface deployments, you want to use the interface to confine the API and the developers to keep them from depending on more than you want to support/advertise.

Collection, provides this feature of minimizing the exposure of implementation in the API. Iterator has the problem that you can only use it once. Iterable backs up the interface one level so that you can get the iterator multiple times.

It provides the same implementation detail visibility occlusion that helps keep the API cleaner, making it much easier to change the implementation.


Posts: 63
Nickname: piglet
Registered: Dec, 2005

Collection is generic Posted: Dec 5, 2005 11:35 AM
Reply to this message Reply
I am surprised that Bruce, of all people, would question the Collection interface. The point of having a common interface is simply to allow the implementation of algorithms in the most general way possible - aka generic programming. It is the Java way of doing generic stuff. For example, when you look at the Collections class, you'll find several useful methods that make sense for any Collection. addAll(), disjoint(), frequency(), min() and max() are applicable to "anything holding objects. The Java way of saying "this is an aggregate of objects" is to have it implement Collection. List and Set have different functions, but nevertheless it may make sense to check whether a given List has an element in commen with a given Set, or to put the elements of a List on a Queue. Without the Collection interface, you'd have to implement non-generic methods for any situation that might possibly arise in order to do stuff like that.

It is true, you could often accomplish the same with iterators, but not always (as has been pointed out before), so using the Collection interface seems to be the most generic solution. I also have the feeling that the idiom is not very appropriate, at least not for Java. Even if disjoint() could be implemented to take Iterators (which it cannot), it wouldn't really make sense to speak of "disjoint iterators" rather than disjoint collections.
Collections have max and min elements, size, an iterator, array representations, can be empty or not. This is really behavior that all Collections have in common and it justifies the Collection interface. Some design details of the API are of course questionable but in principle it works fine for me.

"I would argue that what they appear to have in common is structural rather than functional: all three involve holding objects." Yes, but that's the point. That's why we need this interface, in order to express structure. It's marvellous that we can do this! Same for Iterator, it expresses structure and not function.

Axl Mattheus

Posts: 1
Nickname: axlm
Registered: Oct, 2005

Re: Collection versus Iterator Posted: Dec 7, 2005 7:59 AM
Reply to this message Reply
I have grown fond of using Iterable<T> as a substitute for Collection. For instance a Person would look like this...

interface Person {
Iterable<String> getFirstNames();
void setFirstNames(String... names);
void addFirstName(String name);
void removeFirstName(String name);

Now I am totally independant of the Java Collection Framework.

Flat View: This topic has 18 replies on 2 pages [ « | 1  2 ]
Topic: UML vs OO Design Previous Topic   Next Topic Topic: Scala: An Effective Blend of Object Oriented and Functional Programming

Sponsored Links


Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use