Sponsored Link •
|
Summary
From discussions about the previous weblog entry, I've realized that Collection, Iterator (and Iterable) are all attempts to unify access to containers. Each has strengths and weaknesses, which is probably why we need more than one way to do it.
Advertisement
|
Iterator/Iterable abstract all containers down to "sequences of something," which is why a Map can be included. And if a method can ignore enough of the details of a container, then it's general-purpose enough to be used with an iterator.
But sometimes you want to write a more specific method, so it needs to know more specific information about the type it's dealing with, so you say Collection, Set, List, Queue or Map.
The fact that Set is an exact image of Collection, while Queue could be effectively disjoint from collection and List and ArrayList are extensions -- well, that still has a design smell about it (I actually don't have a problem with the "optional" method design, although I did at first). And Collection would almost certainly have been better if it had been called "Sequence."
After working with some of the "Abstract" container classes (which make it much simpler to implement your own container), I also wonder if the AbstractCollection didn't come first, and then it just seemed like there needed to be an associated Collection interface.
In any case, I'm now more comfortable with the idea that there isn't necessarily going to be "one form of unification to rule them all." Especially without latent typing; C++ STL algorithms can achieve a lot because C++ templates support latent typing.
Speaking of which, the next weblog entry comes from the last few days of programming around the topic of containers, and it's another example of why latent/duck typing is a very important aspect in a generics implementation.
Have an opinion? Readers have already posted 2 comments about this weblog entry. Why not add yours?
If you'd like to be notified whenever Bruce Eckel adds a new entry to his weblog, subscribe to his RSS feed.
Bruce Eckel (www.BruceEckel.com) provides development assistance in Python with user interfaces in Flex. He is the author of Thinking in Java (Prentice-Hall, 1998, 2nd Edition, 2000, 3rd Edition, 2003, 4th Edition, 2005), the Hands-On Java Seminar CD ROM (available on the Web site), Thinking in C++ (PH 1995; 2nd edition 2000, Volume 2 with Chuck Allison, 2003), C++ Inside & Out (Osborne/McGraw-Hill 1993), among others. He's given hundreds of presentations throughout the world, published over 150 articles in numerous magazines, was a founding member of the ANSI/ISO C++ committee and speaks regularly at conferences. |
Sponsored Links
|