3 ms·

You say you don't want to go into the details but you really should in order to strengthen your argument. At the moment you're just using DH2 (Responding to To

You say you don't want to go into the details but you really should in order to strengthen your argument. At the moment you're just using DH2 (Responding to Tone), DH1 (Ad Hominem) and perhaps a little DH0 (Name calling). If you really think the GoF are aiding conmen in tricking the weak-minded, then please substanciate that.

mynameishere 19y ago
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.
- bayareaguy 19y ago
  What the Portland Pattern Repository has to offer here: http://c2.com/cgi-bin/wiki?IteratorPattern 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.
- Tichy 19y ago
  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.

mynameishere 19y ago

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.

bayareaguy 19y ago
What the Portland Pattern Repository has to offer here: http://c2.com/cgi-bin/wiki?IteratorPattern 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.
Tichy 19y ago
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.