I don't have the book to quote it. But roughly, here is how it works:
What is an "Iterator"? It's an object that contains functionality to retrieve objects from a container. Period. The end.
Now, what is an "Iterator Pattern"? (Again, I don't have the book, so...) I think it is about 10-15 pages of how to define, describe, document, specify, graph, implement, re-use, contextualize and otherwise belabour the Iterator object.
But, at the end of the day, an "Iterator" is simply the next-next-next functionality moved from the linked list to another place. That's all it ever is, in practice. The book makes things worse by using PhD-dissertation levels of vocabulary and grammatical structures to describe simple, simple concepts. This gives confusion to people who don't see through the bull, and when they say "Aha! I understand Iterators!", they believe they've unriddled a mystery, and so become "educators" and "advocates" on behalf of others.
I speak from experience, and have no statistics on this.
But most people who start out with "The C Programming Language" and never read "Design Patterns" will only ever use for loops and never think about iterators. How do you want to transmit certain concepts without giving them names?
I also had situations where "Design Patterns" helped me find a solution. Of course I also experienced the IT Manager who wanted to see Design Patterns everywhere, no matter if they were useful or not. But that is not the fault of the book.
What the Portland Pattern Repository has to offer here: http://c2.com/cgi-bin/wiki?IteratorPattern would probably suffice for all but beginning programmers. Much of the additional verbiage comes from their attempt to explain the relationships between the patterns they've identified (e.g. Iterator vs Visitor). Perhaps the book would probably be better if it did less of that, but I think that's more a matter of taste.
What is an "Iterator"? It's an object that contains functionality to retrieve objects from a container. Period. The end.
Now, what is an "Iterator Pattern"? (Again, I don't have the book, so...) I think it is about 10-15 pages of how to define, describe, document, specify, graph, implement, re-use, contextualize and otherwise belabour the Iterator object.
But, at the end of the day, an "Iterator" is simply the next-next-next functionality moved from the linked list to another place. That's all it ever is, in practice. The book makes things worse by using PhD-dissertation levels of vocabulary and grammatical structures to describe simple, simple concepts. This gives confusion to people who don't see through the bull, and when they say "Aha! I understand Iterators!", they believe they've unriddled a mystery, and so become "educators" and "advocates" on behalf of others.
I speak from experience, and have no statistics on this.