Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
As a distinct pattern, Enumeration Method was first properly documented by Kent Beck in Smalltalk Best Practice Patterns.
However, it is not a pattern that is restricted to Smalltalk: it can be applied in C, using function pointers, such as EnumChildWindows in the Windows API; it can be used in Java, based on the common Command pattern and the specific use of inner classes to achieve a sense of closure; it is the common form of iteration in Ruby, which supports blocks as objects directly, and where these are commonly (but confusingly, for our purposes) also known as iterators; for the functional programmers among you, it is in essence the map function from an object-centred perspective.
Of course, the ease with which Enumeration Method can be implemented and used, and therefore its applicability, is an important consideration. It would be too simple to claim that Iterators are necessarily more verbose than Enumeration Methods and that Enumeration Methods are generally superior, for the simple reason that such a claim needs to be made and measured against a specific context. Understanding the role context plays in design is perhaps one of the most important, but most overlooked, aspects of successful pattern application.
In a language where blocks are supported natively as objects, such as Smalltalk and Ruby, implementing Iterators without appropriate cause might be considered quite curious and more than a little gratuitous. However, although it is said that "what's good for the goose is good for the gander", it doesn't follow that it's always such good source for the mongoose.
In a language that doesn't support closures, it turns out that even though implementing the Enumeration Method itself is normally easy, using it can be something of a pain, shifting the complexity from the collection writer to the collection user.
This applies to a greater or lesser degree depending on what other features a language supports and what its native library style is. For example, assuming that closures are adopted in Java 6, Enumeration Method will become easier to implement and use in Java. For the moment, however, although anonymous inner classes make a block-like approach possible, the resulting syntactic overhead is somewhat cumbersome if you aren't getting any obvious additional benefit.
So unless there is a specific reason to do otherwise, such as recursive traversal or synchronized traversal, it is far wiser to favour Iterator as the default approach in Java: both the language and the library are geared up to support it, and writing an Iterator correctly is not a significant challenge.
We could go on to talk about Python's approach to iteration, or the diversity of styles that can be conveniently supported in C# 2.0, or the style of iteration used in C++ that supports the concept of generic programming, or understand how simple and effective map is in Scheme, or the relationship between iteration in Ruby and CLU, and so on. But, for the sake of brevity, I'll stop the language listing there. Hopefully you get the general idea: there is no single option that is best across all languages.
So, whatever its merits elsewhere, if a particular pattern cuts across the grain of a language's features and its received idioms, it is normally easier to go with the flow than against it. You don't want to be writing code that is unnecessarily complex by virtue of an unquestioned idiom import from elsewhere; an idiom that fails to add any noticeable advantage over the more native idiom for a typical case of application.
But let's be clear: that is "normally easier", not "always easier". It pays to be a polyglot: you want your design gestalt to contain more than just a nice set of unquestioned defaults informed only by a single language. To be able to select the mot juste, whatever the situation, you want your design vocabulary to be able to draw on multiple sources. You need more than one idea.
I've already mentioned that for recursive data structures Enumeration Method is much easier to implement than Iterator. Likewise, where you have a collection shared between threads and you want to support uninterrupted traversals, it is much easier to use.
These situations sound quite specific, but having explained why Enumeration Method is a less appropriate approach than Iterator for most uses of iteration in certain of languages, I would like to ensure that not too much design territory is ceded.
COMMENTS
Linguistics
As time goes on it does indeed appear that Java is acquiring more powerful features, but it appears to be at the expense of consistent language design and invariably makes parts of the language more complex. Whether the additional complexity is worth it in all cases is questionable. For many recent and forthcoming features, it might be that Java is simply the wrong base language to extend, i.e. "I wouldn't start from here" :->
In terms of Ruby's iteration, the most obvious influences are Smalltalk, with blocks of code treated as objects, and CLU, with a coroutine-like ability to suspend execution of a block and yield a value (an approach that has since been incorporated into C#).
In Scheme, Enumeration Method is actually most like the for-each function, but as I was focusing on a more strictly functional programming perspective the map function was closer. The fold (or apply or reduce) family of functions found in languages such as Lisp, Scheme, Haskell, etc, is actually not a particularly representative example of an Enumeration Method since, for a single list, each application of the passed function receives two arguments rather than one: one is a list element and the other is the result of the previous application of the function on the previous element (and so on). Definitely useful, but not as direct or simple an example of a straight Enumeration Method.
To enumerate, divine
I haven't been a regular Java user since 1.4, so it slipped my mind that, indeed, Java has specific syntax sugar for the Iterator. It didn't slip my mind that an internal iterator call would look frightful:
col.foreach(new Callable() { public void call(Object obj) {
// loop code goes here
}})
Verity Stob demonstrates in "Out of the (C++) loop", language idiom does (and should) depend on what's legible in the syntax of the language.
If Java 1.6 had closures, as you say, that would open the door for such things. (Is it just me, or is Java getting less nerfed as it goes along?)
I still dislike the idea of having two classes that are so completely interdependent as a Java Collection/Iterator pair. I also find an Iterator's usually (not most classes, most loops -- arrays/lists) an abstraction that adds complexity for no benefit.
And, as I pointed out earlier, 90% of the times you want to iterate over a loop, you do just want to run a bit of code against each object in the collection. The Enumeration pattern is the obvious way to do that without the caller having to worry about the details.
You mention Smalltalk; I believe that's where Ruby gets its iterator style from. And you mention Lisp's map inaccurately. Lisps have other functions that apply a function to each element of a list, notably foldl and family.
IT infrastructure monitoring strategies
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Data control in the cloud
Cloud based data management
Enabling efficient data center monitoring
